MySQL binlog/redolog/undolog 的區(qū)別？

想和大家聊聊 InnoDB 中的鎖機制，那么不可避免的要涉及到 MySQL 的日志系統(tǒng)，binlog、redo log、undo log 等，看到有小伙伴總結的這三個日志還不錯，趕緊拿來和各位小伙伴分享。

日志是mysql數(shù)據庫的重要組成部分，記錄著數(shù)據庫運行期間各種狀態(tài)信息。mysql日志主要包括錯誤日志、查詢日志、慢查詢日志、事務日志、二進制日志幾大類。

作為開發(fā)，我們重點需要關注的是二進制日志(binlog)和事務日志(包括redo log和undo log)，本文接下來會詳細介紹這三種日志。

bin log

binlog用于記錄數(shù)據庫執(zhí)行的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中。binlog是mysql的邏輯日志，并且由Server層進行記錄，使用任何存儲引擎的mysql數(shù)據庫都會記錄binlog日志。

• 邏輯日志：可以理解為記錄的就是sql語句.
• 物理日志：mysql數(shù)據最終是保存在數(shù)據頁中的，物理日志記錄的就是數(shù)據頁變更 。

binlog是通過追加的方式進行寫入的，可以通過max_binlog_size參數(shù)設置每個binlog文件的大小，當文件大小達到給定值之后，會生成新的文件來保存日志。

在實際應用中，binlog的主要使用場景有兩個，分別是主從復制和數(shù)據恢復。

• 主從復制：在Master端開啟binlog，然后將binlog發(fā)送到各個Slave端，Slave端重放binlog從而達到主從數(shù)據一致。
• 數(shù)據恢復：通過使用mysqlbinlog工具來恢復數(shù)據。

binlog刷盤時機

對于InnoDB存儲引擎而言，只有在事務提交時才會記錄biglog，此時記錄還在內存中，那么biglog是什么時候刷到磁盤中的呢？

mysql通過sync_binlog參數(shù)控制biglog的刷盤時機，取值范圍是0-N：

• 0：不去強制要求，由系統(tǒng)自行判斷何時寫入磁盤；
• 1：每次commit的時候都要將binlog寫入磁盤；
• N：每N個事務，才會將binlog寫入磁盤。

從上面可以看出，sync_binlog最安全的是設置是1，這也是MySQL 5.7.7之后版本的默認值。但是設置一個大一些的值可以提升數(shù)據庫性能，因此實際情況下也可以將值適當調大，犧牲一定的一致性來獲取更好的性能。

binlog日志格式

binlog日志有三種格式，分別為STATMENT、ROW和MIXED。

在MySQL 5.7.7之前，默認的格式是STATEMENT，MySQL 5.7.7之后，默認值是ROW。日志格式通過binlog-format指定。

• STATMENT：基于SQL 語句的復制( statement-based replication, SBR )，每一條會修改數(shù)據的sql語句會記錄到binlog 中  。
• ROW：基于行的復制(row-based replication, RBR )，不記錄每條sql語句的上下文信息，僅需記錄哪條數(shù)據被修改了 。
• MIXED：基于STATMENT 和 ROW 兩種模式的混合復制(mixed-based replication, MBR )，一般的復制使用STATEMENT 模式保存 binlog ，對于 STATEMENT 模式無法復制的操作使用 ROW 模式保存 binlog

redo log

為什么需要redo log

我們都知道，事務的四大特性里面有一個是持久性，具體來說就是只要事務提交成功，那么對數(shù)據庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態(tài)。

那么mysql是如何保證一致性的呢？

最簡單的做法是在每次事務提交的時候，將該事務涉及修改的數(shù)據頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題，主要體現(xiàn)在兩個方面：

• 因為Innodb是以頁為單位進行磁盤交互的，而一個事務很可能只修改一個數(shù)據頁里面的幾個字節(jié)，這個時候將完整的數(shù)據頁刷到磁盤的話，太浪費資源了！
• 一個事務可能涉及修改多個數(shù)據頁，并且這些數(shù)據頁在物理上并不連續(xù)，使用隨機IO寫入性能太差！

因此mysql設計了redo log，具體來說就是只記錄事務對數(shù)據頁做了哪些修改，這樣就能完美地解決性能問題了(相對而言文件更小并且是順序IO)。

redo log基本概念

redo log包括兩部分：一個是內存中的日志緩沖(redo log buffer)，另一個是磁盤上的日志文件(redo logfile)。

mysql每執(zhí)行一條DML語句，先將記錄寫入redo log buffer，后續(xù)某個時間點再一次性將多個操作記錄寫到redo log file。這種先寫日志，再寫磁盤的技術就是MySQL
里經常說到的WAL(Write-Ahead Logging)技術。

在計算機操作系統(tǒng)中，用戶空間(user space)下的緩沖區(qū)數(shù)據一般情況下是無法直接寫入磁盤的，中間必須經過操作系統(tǒng)內核空間(kernel space)緩沖區(qū)(OS Buffer)。

因此，redo log buffer寫入redo logfile實際上是先寫入OS Buffer，然后再通過系統(tǒng)調用fsync()將其刷到redo log file
中，過程如下：

mysql支持三種將redo log buffer寫入redo log file的時機，可以通過innodb_flush_log_at_trx_commit參數(shù)配置，各參數(shù)值含義如下：

redo log記錄形式

前面說過，redo log實際上記錄數(shù)據頁的變更，而這種變更記錄是沒必要全部保存，因此redo log實現(xiàn)上采用了大小固定，循環(huán)寫入的方式，當寫到結尾時，會回到開頭循環(huán)寫日志。如下圖：

同時我們很容易得知， 在innodb中，既有redo log需要刷盤，還有數(shù)據頁也需要刷盤，redo log存在的意義主要就是降低對數(shù)據頁刷盤的要求 ** 。

在上圖中，write pos表示redo log當前記錄的LSN(邏輯序列號)位置，check point表示數(shù)據頁更改記錄刷盤后對應redo log所處的LSN(邏輯序列號)位置。

write pos到check point之間的部分是redo log空著的部分，用于記錄新的記錄；check point到write pos之間是redo log待落盤的數(shù)據頁更改記錄。當write pos追上check point時，會先推動check point向前移動，空出位置再記錄新的日志。

啟動innodb的時候，不管上次是正常關閉還是異常關閉，總是會進行恢復操作。因為redo log記錄的是數(shù)據頁的物理變化，因此恢復的時候速度比邏輯日志(如binlog)要快很多。

重啟innodb時，首先會檢查磁盤中數(shù)據頁的LSN，如果數(shù)據頁的LSN小于日志中的LSN，則會從checkpoint開始恢復。

還有一種情況，在宕機前正處于checkpoint的刷盤過程，且數(shù)據頁的刷盤進度超過了日志頁的刷盤進度，此時會出現(xiàn)數(shù)據頁中記錄的LSN大于日志中的LSN，這時超出日志進度的部分將不會重做，因為這本身就表示已經做過的事情，無需再重做。

redo log與binlog區(qū)別

由binlog和redo log的區(qū)別可知：binlog日志只用于歸檔，只依靠binlog是沒有crash-safe能力的。

但只有redo log也不行，因為redo log是InnoDB特有的，且日志上的記錄落盤后會被覆蓋掉。因此需要binlog和redo log二者同時記錄，才能保證當數(shù)據庫發(fā)生宕機重啟時，數(shù)據不會丟失。

undo log

數(shù)據庫事務四大特性中有一個是原子性，具體來說就是原子性是指對數(shù)據庫的一系列操作，要么全部成功，要么全部失敗，不可能出現(xiàn)部分成功的情況。

實際上，原子性底層就是通過undo log實現(xiàn)的。undo log主要記錄了數(shù)據的邏輯變化，比如一條INSERT語句，對應一條DELETE的undo log，對于每個UPDATE語句，對應一條相反的UPDATE的undo log，這樣在發(fā)生錯誤時，就能回滾到事務之前的數(shù)據狀態(tài)。

同時，undo log也是MVCC(多版本并發(fā)控制)實現(xiàn)的關鍵。

到此這篇關于一文搞定MySQL binlog/redolog/undolog區(qū)別的文章就介紹到這了,更多相關mysql binlog/redolog/undolog區(qū)別內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論