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

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

圖片

1 binlog

1.1 binlog 設(shè)計目標(biāo)

binlog 記錄了對MySQL數(shù)據(jù)庫執(zhí)行更改的所有的寫操作，包括所有對數(shù)據(jù)庫的數(shù)據(jù)、表結(jié)構(gòu)、索引等等變更的操作。

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

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

在實(shí)際應(yīng)用中， binlog 的主要應(yīng)用場景分別是 主從復(fù)制 和 數(shù)據(jù)恢復(fù)。

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

圖片

1.2 binlog 數(shù)據(jù)格式

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

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

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

優(yōu)點(diǎn)：不會出現(xiàn)某些特定情況下的存儲過程、或function、或trigger的調(diào)用和觸發(fā)無法被正確復(fù)制的問題；

缺點(diǎn)：會產(chǎn)生大量的日志，尤其是 alter table 的時候會讓日志暴漲。

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

優(yōu)點(diǎn)：不需要記錄每一行的變化，減少了 binlog 日志量，節(jié)約了 IO  , 從而提高了性能；

缺點(diǎn)：在某些情況下會導(dǎo)致主從數(shù)據(jù)不一致，比如執(zhí)行sysdate() 、  slepp()  等 。

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

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

1）使用 row 格式的 binlog 時，在進(jìn)行數(shù)據(jù)同步或恢復(fù)的時候不一致的問題更容易被發(fā)現(xiàn)，因為它是基于數(shù)據(jù)行記錄的。

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

1.3 binlog 寫入策略

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

MySQL 其實(shí)是通過 sync_binlog 參數(shù)控制 biglog 的刷盤時機(jī)，取值范圍是 0-N：

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

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

2、redo log

2.1 redo log 設(shè)計目標(biāo)

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

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

圖片

2.2 redo log 數(shù)據(jù)格式

redo log 包括兩部分：

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

MySQL 每執(zhí)行一條 DML 語句，先將記錄寫入 redo log buffer，后續(xù)某個時間點(diǎn)再一次性將多個操作記錄寫到 redo log file。

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

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

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

圖片

修改數(shù)據(jù)的操作流程：

圖片

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

2.3 關(guān)于 redo log 的幾點(diǎn)疑惑

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

Q1：為什么不直接修改磁盤中的數(shù)據(jù)？

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

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

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

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

我認(rèn)為最核心的一點(diǎn)就是兩者記錄的數(shù)據(jù)變更粒度是不一樣的。

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

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

圖片

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

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

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

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

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

2.4 redo log 寫入策略

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

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

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

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

3、undo log

3.1 undo log設(shè)計目標(biāo)

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

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

undo log 的主要應(yīng)用場景分別：

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

3.2 undo log 數(shù)據(jù)格式

undo log 數(shù)據(jù)主要分兩類：

• insert undo log

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

• update undo log

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

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

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

3.3 undo log 操作實(shí)例

1）首先準(zhǔn)備一張原始原始數(shù)據(jù)表（user_info）

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

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

圖片

2）開啟一個事務(wù)A

對 user_info 表執(zhí)行如下SQL：

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

將會進(jìn)行如下流程操作：

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

3）最后執(zhí)行結(jié)束

結(jié)果如下所示：

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

總結(jié)

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

它的設(shè)計目標(biāo)是支持innodb的“事務(wù)”的特性，事務(wù)ACID特性分別是原子性、一致性、隔離性、持久性， 一致性是事務(wù)的最終追求的目標(biāo)，隔離性、原子性、持久性是達(dá)成一致性目標(biāo)的手段，根據(jù)的之前的介紹我們已經(jīng)知道隔離性是通過鎖機(jī)制來實(shí)現(xiàn)的，而事務(wù)的原子性和持久性則是通過redo log 和undo log來保障的。

寫入策略

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

圖片

binlog vs redo log

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

兩個側(cè)重點(diǎn)也不同， redo log讓InnoDB有了崩潰恢復(fù)的能力，binlog保證了MySQL集群架構(gòu)的數(shù)據(jù)一致性。

圖片

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