MySQL binlog 組提交與 XA(分布式事務、兩階段提交)【轉】

概念：

      XA(分布式事務)規范主要定義了(全局)事務管理器(TM: Transaction Manager)和(局部)資源管理器(RM: Resource Manager)之間的接口。XA為了實現分布式事務，將事務的提交分成了兩個階段：也就是2PC (tow phase commit)，XA協議就是通過將事務的提交分為兩個階段來實現分布式事務。

兩階段：

1）prepare 階段

      事務管理器向所有涉及到的數據庫服務器發出prepare"准備提交"請求，數據庫收到請求后執行數據修改和日志記錄等處理，處理完成后只是把事務的狀態改成"可以提交",然后把結果返回給事務管理器。即：為prepare階段，TM向RM發出prepare指令，RM進行操作，然后返回成功與否的信息給TM。

2）commit 階段

      事務管理器收到回應后進入第二階段，如果在第一階段內有任何一個數據庫的操作發生了錯誤，或者事務管理器收不到某個數據庫的回應，則認為事務失敗，回撤所有數據庫的事務。數據庫服務器收不到第二階段的確認提交請求，也會把"可以提交"的事務回撤。如果第一階段中所有數據庫都提交成功，那么事務管理器向數據庫服務器發出"確認提交"請求，數據庫服務器把事務的"可以提交"狀態改為"提交完成"狀態，然后返回應答。即：為事務提交或者回滾階段，如果TM收到所有RM的成功消息，則TM向RM發出提交指令；不然則發出回滾指令。

實現：

      MySQL中的XA實現分為：外部XA和內部XA。前者是指我們通常意義上的分布式事務實現；后者是指單台MySQL服務器中，Server層作為TM(事務協調者)，而服務器中的多個數據庫實例作為RM，而進行的一種分布式事務，也就是MySQL跨庫事務；也就是一個事務涉及到同一條MySQL服務器中的兩個innodb數據庫(因為其它引擎不支持XA)。

1）內部XA的額外功能：XA 將事務的提交分為兩個階段，而這種實現，解決了 binlog 和 redo log的一致性問題。

      MySQL為了兼容其它非事物引擎的復制，在server層面引入了 binlog, 它可以記錄所有引擎中的修改操作，因而可以對所有的引擎使用復制功能。MySQL在4.x 的時候放棄redo的復制策略而引入binlog。但是引入了binlog，會導致一個問題——binlog和redo log的一致性問題：一個事務的提交必須寫redo log和binlog，那么二者如何協調一致呢？事務的提交以哪一個log為標准？如何判斷事務提交？事務崩潰恢復如何進行？

MySQL通過兩階段提交(內部XA的兩階段提交)很好地解決了這一問題：
第一階段：InnoDB prepare，持有prepare_commit_mutex，並且write/sync redo log； 將回滾段設置為Prepared狀態，binlog不作任何操作；
第二階段：包含兩步，1> write/sync Binlog； 2> InnoDB commit (寫入COMMIT標記后釋放prepare_commit_mutex)；
以binlog 的寫入與否作為事務提交成功與否的標志，innodb commit標志並不是事務成功與否的標志。
此時的事務崩潰恢復過程如下：
1> 崩潰恢復時，掃描最后一個Binlog文件，提取其中的xid； 
2> InnoDB維持了狀態為Prepare的事務鏈表，將這些事務的xid和Binlog中記錄的xid做比較，如果在Binlog中存在，則提交，否則回滾事務。
通過這種方式，可以讓InnoDB和Binlog中的事務狀態保持一致。如果在寫入innodb commit標志時崩潰，則恢復時，會重新對commit標志進行寫入；在prepare階段崩潰，則會回滾，在write/sync binlog階段崩潰，也會回滾

簡而言之就是：先寫redo log，再寫binlog，並以binlog寫成功為事務提交成功的標志。崩潰恢復是以binlog中的xid和redo log中的xid進行比較，xid在binlog里存在則提交，不存在則回滾。

    MySQL XA分為兩類，內部XA與外部XA；

    內部XA用於同一實例下跨多個引擎的事務，由Binlog作為協調者；

    外部XA用於跨多個MySQL實例的分布式事務，需要應用層介入作為協調者(崩潰時的懸掛事務，全局提交還是回滾，需要由應用層決定，對應用層的實現要求較高)；

最常見的內部XA事務存在於binlog與InnoDB存儲引擎之間，從而保證了主從環境的數據一致性。

2）binlog 組提交：

      上面介紹事務的兩階段提交過程是5.6之前版本中的實現，有嚴重的缺陷。當sync_binlog=1時，很明顯上述的第二階段中的 write/sync binlog會成為瓶頸，而且還是持有全局大鎖(prepare_commit_mutex: prepare 和 commit共用一把鎖)，這會導致性能急劇下降。解決辦法就是在MySQL5.6中引進的binlog組提交。

Binlog Group Commit的過程拆分成了三個階段：

1> flush stage 將各個線程的binlog從cache寫到文件中; 
2> sync stage 對binlog做fsync操作（如果需要的話；最重要的就是這一步，對多個線程的binlog合並寫入磁盤）；
3> commit stage 為各個線程做引擎層的事務commit(這里不用寫redo log，在prepare階段已寫)。
每個stage同時只有一個線程在操作。(分成三個階段，每個階段的任務分配給一個專門的線程，這是典型的並發優化)

這種實現的優勢在於三個階段可以並發執行，從而提升效率。注意：prepare階段沒有變，還是write/sync redo log。

(另外：5.7中引入了MTS：多線程slave復制，也是通過binlog組提交實現的，在binlog組提交時，給每一個組提交打上一個seqno，然后在slave中就可以按照master中一樣按照seqno的大小順序，進行事務組提交了。)

題外話：淘寶對binlog group commit進行了進一步的優化，從XA恢復的邏輯我們可以知道，只要保證InnoDB Prepare階段的redo日志在寫Binlog前完成write/sync即可。因此我們對Group Commit的第一個stage的邏輯做了些許修改，大概描述如下：

1. InnoDB Prepare，記錄當前的LSN到thd中； 
2. 進入Group Commit的flush stage；Leader搜集隊列，同時算出隊列中最大的LSN。 
3. 將InnoDB的redo log write/fsync到指定的LSN  (注：這一步就是redo log的組寫入。因為小於等於LSN的redo log被一次性寫入到ib_logfile[0|1]) #放到flush binlog 之后
4. 寫Binlog並進行隨后的工作(sync Binlog, InnoDB commit , etc)

也就是將 redo log的write/sync延遲到了 binlog group commit的 flush stage 之后，sync binlog之前。通過延遲寫redo log的方式，顯式的為redo log做了一次組寫入(redo log group write)，並減少了(redo log) log_sys->mutex的競爭。也就是將 binlog group commit 對應的redo log也進行了 group write. 這樣binlog 和 redo log都進行了優化。

注意：當引入Group Commit后，sync_binlog的含義就變了，假定設為1000，表示的不是1000個事務后做一次fsync，而是1000個事務組。

3）相關參數：

innodb_support_xa：默認為true，表示啟用XA，雖然它會導致一次額外的磁盤flush(prepare階段flush redo log). 但是我們必須啟用，而不能關閉它。因為關閉會導致binlog寫入的順序和實際的事務提交順序不一致，會導致崩潰恢復和slave復制時發生數據錯誤。如果啟用了log-bin參數，並且不止一個線程對數據庫進行修改，那么就必須啟用innodb_support_xa參數。

 

文檔：

http://www.ywnds.com/?p=5798

http://www.ywnds.com/?p=7892