在MySQL 中我們經常會接觸到三個核心日志，它們分別是：binlog、redo log、undo log。

好多同學對于它們可能并不陌生，但是具體區分起來各自的功能用途以及實現原理，那可能認知就會比較模糊了，今天就跟大家一起，來清晰明了的介紹一下這些日志的核心思想和功能原理。

圖片

1 binlog

1.1 binlog 設計目標

binlog 記錄了對MySQL數據庫執行更改的所有的寫操作，包括所有對數據庫的數據、表結構、索引等等變更的操作。

注意：這其中不包含SELECT、SHOW等，因為對數據沒有修改

只要是對數據庫有變更的操作都會記錄到binlog里面來，我們可以把數據庫的數據看做銀行賬戶里的余額，而binlog就相當于我們銀行卡的流水記錄。賬戶余額只是一個結果，至于這個結果怎么來的，那就必須得看流水了。

在實際應用中， binlog 的主要應用場景分別是 主從復制 和 數據恢復。

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

圖片

1.2 binlog 數據格式

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

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

• ROW：基于行的復制（row-based replication, RBR），不記錄每條SQL語句的上下文信息，僅需記錄哪條數據被修改了。如果一個update語句修改一百行數據，那么這種模式下就會記錄100行對應的記錄日志。

優點：不會出現某些特定情況下的存儲過程、或function、或trigger的調用和觸發無法被正確復制的問題；

缺點：會產生大量的日志，尤其是 alter table 的時候會讓日志暴漲。

• STATMENT：基于SQL語句的復制( statement-based replication, SBR )，每一條會修改數據的SQL語句會記錄到 binlog 中 。相對于ROW模式，STATEMENT模式下只會記錄這個 update 的語句，所以此模式下會非常節省日志空間，也避免著大量的IO操作。

優點：不需要記錄每一行的變化，減少了 binlog 日志量，節約了 IO  , 從而提高了性能；

缺點：在某些情況下會導致主從數據不一致，比如執行sysdate() 、  slepp()  等 。

• MIXED：基于 STATMENT 和 ROW 兩種模式的混合復制（mixed-based replication, MBR），一般的復制使用 STATEMENT 模式保存 binlog ，對于一些函數，STATEMENT 模式無法復制的操作使用 ROW 模式保存 binlog。

基于這三種模式需要注意的是：

1）使用 row 格式的 binlog 時，在進行數據同步或恢復的時候不一致的問題更容易被發現，因為它是基于數據行記錄的。

2）使用 mixed 或者 statement 格式的 binlog 時，很多事務操作都是基于SQL邏輯記錄，我們都知道一個SQL在不同的時間點執行它們產生的數據變化和影響是不一樣的，所以這種情況下，數據同步或恢復的時候就容易出現不一致的情況。

1.3 binlog 寫入策略

對于 InnoDB 存儲引擎而言，在進行事務的過程中，首先會把binlog 寫入到binlog cache中（因為寫入到cache中會比較快，一個事務通常會有多個操作，避免每個操作都直接寫磁盤導致性能降低），只有在事務提交時才會記錄 biglog ，此時記錄還在內存中，那么 biglog 是什么時候刷到磁盤中的呢？

MySQL 其實是通過 sync_binlog 參數控制 biglog 的刷盤時機，取值范圍是 0-N：

• 0：每次提交事務binlog不會馬上寫入到磁盤，而是先寫到page cache。不去強制要求，由系統自行判斷何時寫入磁盤，在Mysql 崩潰的時候會有丟失日志的風險；
• 1：每次提交事務都會執行 fsync 將 binlog 寫入到磁盤；
• N：每次提交事務都先寫到page cach，只有等到積累了N個事務之后才 fsync 將 binlog 寫入到磁盤，在 MySQL 崩潰的時候會有丟失N個事務日志的風險。

很顯然三種模式下，sync_binlog=1 是強一致的選擇，選擇0或者N的情況下在極端情況下就會有丟失日志的風險，具體選擇什么模式還是得看系統對于一致性的要求。

2、redo log

2.1 redo log 設計目標

redo log 是屬于引擎層(innodb)的日志，稱為重做日志 ，當MySQL服務器意外崩潰或者宕機后，保證已經提交的事務持久化到磁盤中（持久性）。

它能保證對于已經COMMIT的事務產生的數據變更，即使是系統宕機崩潰也可以通過它來進行數據重做，達到數據的持久性，一旦事務成功提交后，不會因為異常、宕機而造成數據錯誤或丟失。

圖片

2.2 redo log 數據格式

redo log 包括兩部分：

• 內存中的日志緩沖（redo log buffer）
• 內存層面，默認16M，通過innodb_log_buffer_size參數可修改
• 磁盤上的日志文件（redo logfile）
• 持久化的，磁盤層面

MySQL 每執行一條 DML 語句，先將記錄寫入 redo log buffer，后續某個時間點再一次性將多個操作記錄寫到 redo log file。

通常所說的Write-Ahead Log(預先日志持久化)指的是在持久化一個數據頁之前，先將內存中相應的日志頁持久化。

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

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

圖片

修改數據的操作流程：

圖片

• 先將原始數據從磁盤中讀入內存中來，修改數據的內存拷貝，產生臟數據
• 生成一條重做日志并寫入redo log buffer，記錄的是數據被修改后的值
• 默認在事務提交后將redo log buffer中的內容刷新到redo log file，對redo log file采用追加寫的方式
• 定期將內存中修改的數據刷新到磁盤中（這里說的是那些還沒及時被后臺線程刷盤的臟數據）

2.3 關于 redo log 的幾點疑惑

讀到這里，相必有同學會有如下疑問：

Q1：為什么不直接修改磁盤中的數據？

因為直接修改磁盤數據的話，它是隨機IO，修改的數據分布在磁盤中不同的位置，需要來回的查找，所以命中率低，消耗大，而且一個小小的修改就不得不將整個頁刷新到磁盤，利用率低；

與之相對的是順序IO，磁盤的數據分布在磁盤的一塊，所以省去了查找的過程，節省尋道時間。

使用后臺線程以一定的頻率去刷新磁盤可以降低隨機IO的頻率，增加吞吐量，這是使用buffer pool的根本原因。

Q2：同為操作數據變更的日志，有了binlog為什么還要redo log？

我認為最核心的一點就是兩者記錄的數據變更粒度是不一樣的。

以修改數據為例，binlog 是以表為記錄主體，在ROW模式下，binlog保存的表的每行變更記錄。

MySQL 是以頁為單位進行刷盤的，每一頁的數據單位為16K，所以在刷盤的過程中需要把數據刷新到磁盤的多個扇區中去。而把16K數據刷到磁盤的每個扇區里這個過程是無法保證原子性的，如果數據庫宕機，那么就可能會造成一部分數據成功，而一部分數據失敗的情況。而通過 binlog 這種級別的日志是無法恢復的，因為一個update可能更改了多個磁盤區域的數據，所以這個時候得需要通過redo log這種記錄到磁盤數據級別的日志進行數據恢復。

圖片

由以上兩者的對比可知：binlog 日志只用于歸檔，只依靠 binlog 是沒有 crash-safe 能力的。

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

Q3：redo log一定能保證事務的持久性嗎？

不一定，這要根據redo log的刷盤策略決定，因為redo log buffer同樣是在內存中，如果提交事務之后，redo log buffer還沒來得及將數據刷新到redo log file進行持久化，此時發生宕機照樣會丟失數據。

那該如何解決呢？刷盤寫入策略。

2.4 redo log 寫入策略

當redo log空間滿了之后又會從頭開始以循環的方式進行覆蓋式的寫入。MySQL 支持三種將 redo log buffer 寫入 redo log file 的時機，可以通過 innodb_flush_log_at_trx_commit 參數配置，各參數含義如下：

• 0（延遲寫）：表示每次事務提交時都只是把 redo log 留在 redo log buffer 中，開啟一個后臺線程，每1s刷新一次到磁盤中 ;
• 1（實時寫，實時刷）：表示每次事務提交時都將 redo log 直接持久化到磁盤，真正保證數據的持久性；
• 2（實時寫，延遲刷）：表示每次事務提交時都只是把 redo log 寫到 page cache，具體的刷盤時機不確定。

除了上面幾種機制外，還有其它兩種情況會把redo log buffer中的日志刷到磁盤。

• 定時處理：有線程會定時(每隔 1 秒)把redo log buffer中的數據刷盤。
• 根據空間處理：redo log buffer 占用到了一定程度( innodb_log_buffer_size 設置的值一半)占，這個時候也會把redo log buffer中的數據刷盤。

3、undo log

3.1 undo log設計目標

redo log 是也屬于引擎層(innodb)的日志，從上面的redo log介紹中我們就已經知道了，redo log 和undo log的核心是為了保證innodb事務機制中的持久性和原子性，事務提交成功由redo log保證數據持久性，而事務可以進行回滾從而保證事務操作原子性則是通過undo log 來保證的。

原子性 是指對數據庫的一系列操作，要么全部成功，要么全部失敗，不可能出現部分成功的情況。

undo log 的主要應用場景分別：

• 事務回滾 ：前面提到過，后臺線程會不定時的去刷新buffer pool中的數據到磁盤，但是如果該事務執行期間出現各種錯誤(宕機)或者執行rollback語句，那么前面刷進去的操作都是需要回滾的，保證原子性，undo log就是提供事務回滾的。
• MVCC：當讀取的某一行被其他事務鎖定時，可以從undo log中分析出該行記錄以前的數據版本是怎樣的，從而讓用戶能夠讀取到當前事務操作之前的數據——快照讀。

3.2 undo log 數據格式

undo log 數據主要分兩類：

• insert undo log

insert 操作的記錄，只對事務本身可見，對其他事務不可見(這是事務隔離性的要求)，故該undo log可以在事務提交后直接刪除，不需要進行purge操作。

• update undo log

update undo log記錄的是對delete和update操作產生的undo log。該undo log可能需要提供MVCC機制，因此不能在事務提交時就進行刪除。提交時放入undo log鏈表，等待purge線程進行最后的刪除。

在InnoDB存儲引擎中，undo log使用rollback segment回滾段進行存儲，每隔回滾段包含了1024個undo log segment。MySQL5.5之后，一共有128個回滾段。即總共可以記錄128 * 1024個undo操作。

每個事務只會使用一個回滾段，一個回滾段在同一時刻可能會服務于多個事務。

3.3 undo log 操作實例

1）首先準備一張原始原始數據表（user_info）

對于InnoDB引擎來說，每個行記錄除了記錄本身的數據之外，還有幾個隱藏的列:

• DB_ROW_ID∶記錄的主鍵id。
• DB_TRX_ID：事務ID，當對某條記錄發生修改時，就會將這個事務的Id記錄其中。
• DB_ROLL_PTR︰回滾指針，版本鏈中的指針。

圖片

2）開啟一個事務A

對 user_info 表執行如下SQL：

update user_info set name =“李四”where id=1

將會進行如下流程操作：

• 首先獲得一個事務編號 104
• 把user_info表修改前的數據拷貝到undo log
• 修改user_info表 id=1的數據
• 把修改后的數據事務版本號改成 當前事務版本號，并把DB_ROLL_PTR 地址指向undo log數據地址。

3）最后執行結束

結果如下所示：

可以發現每次對數據的變更都會產生一個undo log，當一條記錄被變更多次時，那么就會產生多條undo log，undo log記錄的是變更前的日志，并且每個undo log的序號是遞增的，那么當要回滾的時候，按照序號依次向前推，就可以找到我們的原始數據了。

總結

binlog 是MySQL server層的日志，而redo log 和undo log都是引擎層（InnoDB）的日志，要換其他數據引擎那么就未必有redo log和undo log了。

它的設計目標是支持innodb的“事務”的特性，事務ACID特性分別是原子性、一致性、隔離性、持久性， 一致性是事務的最終追求的目標，隔離性、原子性、持久性是達成一致性目標的手段，根據的之前的介紹我們已經知道隔離性是通過鎖機制來實現的，而事務的原子性和持久性則是通過redo log 和undo log來保障的。

寫入策略

事務執行過程中，先把日志寫到bin log cache ，事務提交的時候，再把binlog cache寫到binlog文件中。因為一個事務的binlog不能被拆開，無論這個事務多大，也要確保一次性寫入，所以系統會給每個線程分配一個塊內存作為binlog cache。

圖片

binlog vs redo log

• redo log 物理日志：記錄內容是“在xx數據頁做了xx修改”，屬于InnoDB存儲引擎層產生的。
• binlog 邏輯日志：記錄內容是語句的原始邏輯，類似于給ID=2這一行的c字段加1，屬于服務層。

兩個側重點也不同， redo log讓InnoDB有了崩潰恢復的能力，binlog保證了MySQL集群架構的數據一致性。

圖片

在執行更新語句過程，會記錄redo log與binlog兩塊日志，以基本的事務為單位，redo log在事務執行過程中可以不斷寫入，而binlog只有在提交事務時才寫入，所以redo log與binlog的寫入時機不一樣。