　　1 原理

　　關於MySQL資料庫的分散式事務XA，分散式事務實現的原理，可見[3];關於MySQL XA的說明，可見[1][2]。

　　MySQL XA分為兩類，內部XA與外部XA;內部XA用於同一例項下跨多個引擎的事務，由大家熟悉的Binlog作為協調者;外部XA用於跨多MySQL例項的分散式事務，需要應用層介入作為協調者(崩潰時的懸掛事務，全域性提交還是回滾，需要由應用層決定，對應用層的實現要求較高);

　　本文，假設讀者已經知道MySQL資料庫外部分散式事務XA的使用，而將重點放在MySQL資料庫，如何處理外部分散式事務XA的crash recover，以及面對不同的crash recover的情形，應用程式如何處理，才能夠保證分散式事務的一致性。最後，本文簡單分析一下目前MySQL資料庫外部XA支援存在的問題，以及可選的解決方案。

　　原始碼分析基於MySQL 5.1.49，MySQL 5.5.16。

　　2 MySQL處理流程

　　2.1 MySQL 外部XA – 正常處理流程

　　MySQL資料庫外部XA的正常處理流程，這裡不準備介紹，可以參考[1][2][3]。接下來我重點描述一下MySQL資料庫外部分散式事務XA的崩潰恢復流程，畢竟此流程跟應用程式如何正確使用外部XA息息相關。

　　2.2 MySQL外部XA – 崩潰恢復流程

　　若一個執行外部XA分散式事務的MySQL資料庫節點發生崩潰，那麼其重啟之後的崩潰恢復，涉及到外部XA處理的流程如下：

　　Crash recover：

// 1. 讀取binlog檔案，將檔案中的xid存入commit_list hash表
　　// 顧名思義，所謂的commit_list，就是說此list中對應prepare狀態的xid
　　// 在崩潰恢復過程中均可以被提交，而不在commit_list中的xid，均須回滾
　　// binlog中的xid，都是屬於內部xid，由MySQL產生，用於內部XA
　　Log.cc::TC_LOG_BINLOG::recover
　　// 2. 遍歷底層所有的事務引擎，收集處於XA_PREPARED狀態的所有xid
　　// 這些xid列表，既包括內部xid，也包括外部xid，儲存引擎內部不做區分
　　Handler.cc::ha_recover(commit_list)
　　// 執行各引擎層面提供的recover方法，收集所有的處於prepared狀態的xid
　　// 根據xid分類：
　　// 3. 若xid屬於內部xid，那麼在commit_list中查詢此xid，
　　// 若存在，則提交此xid對應的事務;否則，回滾此事務
　　// 4. 若xid屬於外部xid，那麼則將xid插入xid_cache hash表
　　// xid_cache中的所有xid，將會透過xa recover命令返回，等待外部程式決策
　　Handler.cc::xarecover_handlerton
　　// 5. 收集InnoDB儲存引擎中，處於prepare狀態的所有xid，並返回
　　got = hton->recover (innobase_xa_recover)
　　my_xid x = info->list[i].get_my_xid();
　　if (!x)
　　// 若當前為外部xid，那麼將xid插入xid_cache hash表
　　xid_cache_insert(&xid_cache, x);
　　else
　　if (x in commit_list)
　　// 若當前為內部xid，同時此xid在binlog中存在，則提交
　　hton->commit_by_xid();
　　else
　　// 若當前為內部xid，同時此xid在binlog中不存在，則回滾
　　hton->rollback_by_xid();

　　透過以上的分析，可以總結出：

　　MySQL資料庫內部，會對xid做區分。內部xid有MySQL資料庫自己產生(MySQL內部xid格式，將在本文下面給出)，用於多引擎間事務的一致性;外部xid由應用程式給出，用於跨多MySQL例項的分散式事務。但是儲存引擎層不做區分(區分在MySQL上層)。

　　crash recover時，儲存引擎負責將引擎內部，處於prepare狀態的事務收集，並返回MySQL上層。

　　Binlog作為內部XA的協調者[5]，在binlog中出現的內部xid，在crash recover時，由binlog負責提交;在binlog中未出現的xid，由binlog負責回滾。(這是因為，binlog不進行prepare，只進行commit，因此在binlog中出現的內部xid，一定能夠保證其在底層各儲存引擎中已經完成prepare)。

　　外部XA事務的xid，在crash recover過程中僅僅是插入xid_cache中，而不做其他處理。等到使用者發起xa recover命令時，將xid_cache中處於prepare狀態的xid返回。

　　xa recover命令的流程處理如下。

　　xa recover命令處理流程：

sql_parse.cc::mysql_execute_command
　　case SQLCOM_XA_RECOVER:
　　mysql_xa_recover();
　　// 遍歷xid_cache，找出其中的狀態處於XA_PREPARED的事務，傳送客戶端
　　while (xs = hash_element(&xid_cache,))
　　if (xs->xa_state == XA_PREPARED)
　　protocol->write();

　　根據xa recover命令收集到的各MySQL資料庫例項返回的xid列表，然後再對比應用程式端日誌，決定這些xid，哪些全域性commit，哪些rollback。

　　由於測試中只有一個MySQL資料庫例項，因此此時可以直接選擇commit處於prepare狀態的xid。

　　注：

MySQL內部xid格式： MYSQL_XID_PREFIX + server_id + my_xid
MYSQL_XID_PREFIX： MySQLXid (原始碼寫死) 8 bytes
server_id： MySQL例項的id，ulong， 4 bytes
my_xid：內部自增序列，ulonglong， 8 bytes
例如：”MySQLXid 0004”
server_id = ‘ ’;my_xid = 4

　　因此，使用時應該注意，不要在外部構造這種形式的xid，否則MySQL資料庫就會將內部xid與外部xid混淆。

　　一般情況下，構造一個內部xid比較困難，由於server_id一般小於4 bytes，不足的部分以ASCI NIL(null)補齊，而應用程式一般都不會構造此類的外部xid。

參考資料

[1] Sergei Golubchik. Distributed Transaction Processing with MySQL XA

[2] http://dev.mysql.com/doc/refman/5.1/en/xa.html

[3] X/Open. Distributed TP: The XA Specification

[4] 陳思儒. Amoeba

[5] MariaDB WorkLog#132: Transaction coordinator plugin

該文章出自

MySQL資料庫分散式事務XA的實現原理分析

相關文章