MySQL 兩階段提交

在mysql中，所謂的兩階段提交就是redo log和binlog 兩個階段的commit過程。

在兩階段提交的不同時刻，mysql 異常重啟會出現什麼現象？

1、在時刻 a 發生宕機，也就是寫入 redo log 處於 prepare 階段之後、寫 binlog 之前，發生了崩潰（crash），由於此時 binlog 還沒寫，redo log 也還沒提交，所以崩潰恢復的時候，這個事務會回滾。這時候，binlog 還沒寫，所以也不會傳到備庫。

2、在時刻 b發生宕機，也就是 binlog 寫完，redo log 還沒 commit 前發生 crash，那崩潰恢復的時候 mysql 會怎麼處理？

如果 redo log 裡面的事務是完整的，也就是已經有了 commit 標識，則直接提交；

如果 redo log 裡面的事務只有完整的 prepare，則判斷對應的事務 binlog 是否存在並完整：

a. 如果是，則提交事務；

b. 否則，回滾事務。

乙個事務的 binlog 是有完整格式的：

statement 格式的 binlog，最後會有 commit；

row 格式的 binlog，最後會有乙個 xid event。

mysql 5.6.2 版本以後，還引入了 binlog-checksum 引數，用來驗證 binlog 內容的正確性。

它們有乙個共同的資料字段，叫 xid。

崩潰恢復的時候，會按順序掃瞄 redo log：如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；

如果碰到只有 parepare、而沒有 commit 的 redo log，就拿著 xid 去 binlog 找對應的事務。

推薦直接將 redo log 設定為 4 個檔案、每個檔案 1gb 吧。

redo log 並沒有記錄資料頁的完整資料，所以它並沒有能力自己去更新磁碟資料頁，也就不存在「資料最終落盤，是由 redo log 更新過去」的情況。

如果是正常執行的例項的話，資料頁被修改以後，跟磁碟的資料頁不一致，稱為髒頁。最終資料落盤，就是把記憶體中的資料頁寫盤。這個過程，甚至與 redo log 毫無關係。

在崩潰恢復場景中，innodb 如果判斷到乙個資料頁可能在崩潰恢復的時候丟失了更新，就會將它讀到記憶體，然後讓 redo log 更新記憶體內容。更新完成後，記憶體頁變成髒頁，就回到了第一種情況的狀態。

redo log buffer 就是一塊記憶體，用來先存 redo 日誌的。也就是說，在執行第乙個 insert 的時候，資料的記憶體被修改了，redo log buffer 也寫入了日誌。

真正把日誌寫到 redo log 檔案（檔名是 ib_logfile+ 數字），是在執行 commit 語句的時候做的。~~~~這個做法類似於unbuffered database的做法。

binlog 沒有能力恢復「資料頁」。我理解binlog只能實現邏輯上的重做。

innodb 引擎使用的是 wal 技術，執行事務的時候，寫完記憶體和日誌，事務就算完成了。如果之後崩潰，要依賴於日誌來恢復資料頁。

在正式的生產庫上，binlog 都是開著的。因為 binlog 有著 redo log 無法替代的功能。

乙個是歸檔。redo log 是迴圈寫，寫到末尾是要回到開頭繼續寫的。這樣歷史日誌沒法保留，redo log 也就起不到歸檔的作用。~~~~換言之，mysql redo log的歸檔功能其實是沒有的，和其他主流的商業資料庫是不一樣的。

乙個就是 mysql 系統依賴於 binlog。binlog 作為 mysql 一開始就有的功能，被用在了很多地方。其中，mysql 系統高可用的基礎，就是 binlog 複製。~~~也是因為redo log無法歸檔，也沒有辦法被及時的應用到其他資料庫上，所以只能靠binlog去實現邏輯上的重做來保證主備一致。

MySQL 兩階段提交

MySQL兩階段提交

mysql5 7兩階段提交 mysql兩階段提交

兩階段提交

MySQL 兩階段提交

MySQL兩階段提交

mysql5 7兩階段提交 mysql兩階段提交

兩階段提交

相關推薦