資料的一致性和完整性對於線上業務的重要性不言而喻，如何保證資料不丟呢？今天我們就探討下關於資料的完整性和強一致性，MySQL做了哪些改進。

一. MySQL的二階段提交

在Oracle和MySQL這種關係型資料庫中，講究日誌先行策略（Write-Ahead Logging）,只要日誌持久化到磁碟，就能保證MySQL異常重啟後，資料不丟失。在MySQL中，提到日誌不得不提的就是redo log和binlog。

1. redo log

redo log又稱重做日誌檔案，詳細的記錄了對每一個數據頁裡面的資料行的修改，記錄的是資料修改之後的值。Redo log是用來做資料庫crash recovery的，是保證資料安全的非常重要的功能之一。

redo log的寫入的方式是順序寫、迴圈寫，通過innodb_log_file_size和innodb_log_files_in_group兩個引數控制redo log的檔案大小和個數。redo log在寫入磁碟前會先寫redo log buffer中，大小由innodb_log_buffer_size控制。日誌在寫入redo log buffer後是如何持久化到磁碟的呢？為了控制redo log的寫入策略，Innodb根據innodb_flush_log_at_trx_commit引數不同的取值採用不同的策略，它有三種不同的取值：

• 1. 設定為 0 的時候：事務提交時由MySQL的後臺Master執行緒每隔1秒將快取區的檔案重新整理到日誌檔案中。
• 2. 設定為 1 的時候，表示每次事務提交時都將 redo log 直接持久化到磁碟，保證了事務日誌不丟失，但會對資料庫效能稍有影響。
• 3. 設定為 2 的時候，表示每次事務提交時都只是把 redo log 寫到 日誌檔案中，但不會刷盤，由檔案系統自行刷磁碟。

三種模式下，0的效能最好，但是不安全，MySQL程序一旦崩潰會導致丟失一秒的資料。1的安全性最高，但是對效能影響最大，2的話主要由作業系統自行控制刷磁碟的時間，如果僅僅是MySQL宕機，對資料不會產生影響，如果是主機異常宕機了，同樣會丟失資料。

2. binlog

binlog又稱二進位制日誌，記錄了對MySQL資料庫執行更改的所有操作，不包含select和show操作，主要起到了恢復、複製、審計等功能。Binlog的格式主要有statement、row、mixed三種。

Statement：基於操作的SQL語句記錄到binlog中，不建議使用。

Row：基於行的變更情況記錄，會記錄行更改前後的內容，row模式也是資料庫不丟資料的重要保證，推薦使用。

Mixed：混合前兩個模式，不建議使用。

Binlog的寫入邏輯也比較簡單：事務執行過程中，先寫入binlog cache,事務提交時再寫入binlog檔案。binlog cache由binlog_cache_size和max_binlog_size引數控制，每個執行緒分配一個binlog cache,但是共用binlog檔案。

Binlog的寫入日誌檔案的機制由sync_binlog控制：

• 1. sync_binlog=0 的時候，表示每次提交事務都只 write，不 fsync；
• 2. sync_binlog=1 的時候，表示每次提交事務都會執行 fsync，將資料刷盤；
• 3. sync_binlog=N(N>1) 的時候，表示n次事務提交之後，MySQL才進行一次fsync動作，將binlog cache中的資料刷入磁碟。

innodb_flush_log_at_trx_commit和sync_binlog都設定為1是MySQL資料中經典的雙一模式，是資料庫不丟資料的保障。

MySQL資料採取WAL機制就是為了減少每次髒資料刷盤帶來的效能影響，如果設定”雙一”策略會不會影響資料庫的效能呢？其實這主要得益於redo log和binlog都是順序寫，磁碟的順序寫比隨機寫的速度要快的多，加上MySQL內部的組提交機制，已經大幅降低了對磁碟的IOPS消耗了。

3. 兩階段提交

MySQL引入二階段提交（two phase commit or 2pc），MySQL內部會將普通事務當做一個XA事務（內部分散式事務）來處理,會自動為每個事務分配一個唯一的ID（XID），COMMIT會被動的分成Prepare和Commit兩個階段。

第一階段：Transaction Prepare Phase

此時SQL已經成功執行，並生成xid資訊及redo和undo的記憶體日誌。然後呼叫prepare方法完成第一階段，將事務狀態設為TRX_PREPARED，並將redo log刷盤。

第二階段：Commit Phase

如果事務第一階段進入prepare階段，則將產生的binlog寫入檔案並刷盤，此時事務已經鐵定要提交了。

具體異常場景分析：

1. 當事務在prepare階段crash，資料庫recovery的時候該事務未寫⼊Binary log並且儲存引擎未提交，則該事務rollback。

2. 當事務在binlog階段crash，此時⽇志還沒有成功寫⼊到磁碟中，啟動時會rollback此事務。3. 當事務在binlog⽇志已經fsync()到磁碟後crash，但是InnoDB沒有來得及commit，此時MySQL資料庫recovery的時候將會讀出⼆進位制⽇志的Xid_log_event，然後告訴InnoDB提交這些XID的事務，InnoDB提交完這些事務後會回滾其它的事務，使儲存引擎和⼆進位制⽇志始終保持⼀致。

MySQL的二階段提交就保證了資料庫在異常宕機重啟後的資料不丟失。

二. Double Write

前面我們說了，redo log、binlog以及二階段提交保證了資料在MySQL異常重啟後能夠通過前滾和回滾恢復資料。MySQL在recovery時通過redo log進行恢復，redo log記錄的是頁上的物理操作，但是這裡有個問題，如果頁本身就是錯的，比如發生頁的部分寫問題(頁大小是 16K，假設在把記憶體中的髒頁寫到資料庫的時候，寫了4K 突然掉電。也就是前兩 4K 是新的，後 12K 是舊的，那麼這個資料頁就是不完整的，是一個壞掉的資料頁),這時redo恢復的時候會去校驗資料頁的完整性，此時資料頁已經損壞了，故無法使用 redo log 進行恢復，這個資料就丟失了。

Double Write原理:

1、當重新整理緩衝池髒頁時，並不直接寫到資料檔案中，而是先拷貝至double write buffer。

2、然後從double write buffer分兩次寫入磁碟共享表空間中，每次寫入 1MB。

3、最後再從double write buffer寫入資料檔案。雖然資料總是寫入兩次，但是由於double write 寫入的時候是順序寫，實際上也就犧牲了系統性能的 10%左右。

這樣就可以解決上文提到的部分寫失效的問題，因為在磁碟共享表空間中已有資料頁副本拷貝，如果資料庫在頁寫入資料檔案的過程中宕機，在例項恢復時，可以從共享表空間中找到該頁副本，將其拷貝覆蓋原有的資料頁，再應用重做日誌即可。

3. 小結

今天我們聊了MySQL的二階段提交和double write機制，分別解決了在MySQL宕機重啟以及發生頁的部分寫的場景下，MySQL是如何做到不丟失資料。那如果我們的作業系統宕機無法啟動了，又該怎麼辦呢？MySQL在叢集架構中又做了哪些優化來保證資料不丟失呢？我們下一章再來和大家分享MySQL在叢集架構中的優化改進。