溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
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。
注：
因此，使用時應該注意，不要在外部構造這種形式的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
該文章出自 http://www.searchdatabase.com.cn/showcontent_58646.htm
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
