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。
mysql處理流程
1.mysql 外部xa – 正常處理流程
mysql資料庫外部xa的正常處理流程，這裡不準備介紹，可以參考[1][2][3]。接下來我重點描述一下mysql資料庫外部分布式事務xa的崩潰恢復流程，畢竟此流程跟應用程式如何正確使用外部xa息息相關。
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。
mysql 分布式事務（xa）
這是寫的乙個測試分布式事務的指令碼，參考了網上的乙個指令碼，但是那個在我這裡指令碼不能正常執行，就自己改了一下 mapfarm new mysqli 10.128.51.121 public public db1 or die mapfarm 連線失敗 map new mysqli 10.128.5...
詳解Mysql分布式事務XA（跨資料庫事務）
在開發中，為了降低單點壓力，通常會根據業務情況進行分表分庫，將表分布在不同的庫中 庫可能分布在不同的機器上 在這種場景下，事務的提交會變得相對複雜，因為多個節點 庫 的存在，可能存在部分節點提交失敗的情況，即事務的acid特性需要在各個不同的資料庫例項中保證。比如更新db1庫的a表時，必須同步更新d...
分布式 （XA）事務
在談到 xa規範之前，必須首先了解分布式事務處理 distributed transaction processing dtp 的概念。transaction 即事務，又稱之為交易，指乙個程式或程式段，在乙個或多個資源如 資料庫 或檔案上為完成某些功能的執行過程的集合。分布式事務處理是指乙個事務可能...