MySQL資料庫分布式事務XA實作原理分析

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();

　　// 若目前為内部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。

本文轉自 wws5201985 51CTO部落格，原文連結：http://blog.51cto.com/wws5201985/789451，如需轉載請自行聯系原作者