mysql兩階段提交和組提交

     出於效能的考慮，事務在提交時為了保證資料安全，需要將 redo 和 undo 資料落盤，不用等待資料落盤。但是 mysql 不僅要考慮 innodn 儲存引擎層的 redo 資料，還要考慮資料庫上層的 binlog 資料落盤，已經兩個層面資料落盤的順序問題。兩階段提交可以解決單個事務 redo 和 binlog 落盤順序的問題。

兩階段提交（ 2PC ）分為兩個過程：

l   準備階段（ prepare phase ）

生成 xid 資訊，回滾段設定為 prepare 狀態，並將 redo 落盤。

l   提交階段（ commit phase ）

在 binlog 生成 commit 的 XID event ， Binlog 落盤，釋放回滾段，釋放鎖。

 

二階段提交的回滾：
       只寫了redo，沒落盤binlog，回滾。

落盤了redo，binlog落盤成功了，也有commit XID，自然是成功。

落盤了redo，binlog落盤成功了，沒有commit XID，也認為事務已提交。

現在再來思考下一個問題，如果每個事物提交的時候，都要去將 redo 和 binlog 落盤，那麼瓶頸就在落盤階段被放大了。這個時候就要引入組提交。組提交使得 redo 和 binlog 落盤的時候可以批量落盤，多個事務的 redo 和 binlog 可以一次 fsync 操作完成資料落盤，減少了 fsync 函式的呼叫，提高了效率。同時 innodb 儲存引擎層本身就支援組提交。

 

組提交之後，引入了另一個問題。資料庫上層的 binlog 寫入順序和 innodb 層事務提交順序無法保持一致。如果不保持一致，那麼就會出現通過線上工具比如 xtrabackup 備份資料庫搭建主從的時候，出現丟失事務的場景，比如下面：

                                             

      binlog 提交順序（ T1,T2,T3 ）， innodb commit 順序（ T2,T3,T1 ），此時 innodb 檢測到 T3 上下兩層都已經提交，認為不再需要恢復，那麼 T1 事務在備份的時候沒有經歷兩階段提交， T1 的事務在備份的時候資料還是事務開始前的資料，從庫又不再進行恢復，導致 T1 事務被丟棄。所以後來引進了 prepare_commit_mutex, 以序列的方式來保證順序，但是這樣會使組提交失效，所以後來提出了 BLGC （ binary log group commit ）

該行為分為三個階段

Flush 階段

記憶體中生成事務的二進位制日誌

Sync 階段

將記憶體中多個事務的二進位制日誌呼叫 1 次 fsync 刷盤

Commit 階段

二進位制日誌在記憶體中會有一個佇列，佇列第一個事務是 leader ，其他時 follower ， leader 會根據順序呼叫儲存引擎層事務提交。 Innodb 本身就支援組提交。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31480688/viewspace-2696699/，如需轉載，請註明出處，否則將追究法律責任。