分布式事務(wù)：MySQL中的XA事務(wù)崩潰了如何恢復(fù)？

前段時間搭建了一套MySQL分布式數(shù)據(jù)庫集群，數(shù)據(jù)庫節(jié)點有12個，用來測試各種分布式事務(wù)方案的性能和優(yōu)缺點。測試MySQL XA事務(wù)時，正當測試腳本向數(shù)據(jù)庫中批量插入數(shù)據(jù)時，強制服務(wù)器斷電！注意：是直接拔電源，使其瞬間斷電，再次重啟服務(wù)器后，MySQL數(shù)據(jù)庫報錯了。特此記錄MySQL XA事務(wù)的恢復(fù)。

MySQL XA事務(wù)問題

服務(wù)器強制斷電后重啟，此時MySQL報錯，查看MySQL啟動日志時，發(fā)現(xiàn)如下所示的錯誤信息。

InnoDB:?The?log?sequence?number?in?ibdata?files?does?not?match
InnoDB:?the?log?sequence?number?in?the?ib_logfiles!
100224?23:24:20?InnoDB:?Database?was?not?shut?down?normally!
InnoDB:?Starting?crash?recovery.
InnoDB:?Reading?tablespace?information?from?the?.ibd?files...
InnoDB:?Restoring?possible?half-written?data?pages?from?the?doublewrite
InnoDB:?buffer...
InnoDB:?Transaction?0?4497755?was?in?the?XA?prepared?state.
InnoDB:?Transaction?0?4468551?was?in?the?XA?prepared?state.
InnoDB:?Transaction?0?4468140?was?in?the?XA?prepared?state.
InnoDB:?3?transaction(s)?which?must?be?rolled?back?or?cleaned?up
InnoDB:?in?total?0?row?operations?to?undo
InnoDB:?Trx?id?counter?is?0?5312768
InnoDB:?Starting?in?background?the?rollback?of?uncommitted?transactions
100224?23:24:20?InnoDB:?Rollback?of?non-prepared?transactions?completed
100224?23:24:20?InnoDB:?Started;?log?sequence?number?0?3805002509
100224?23:24:20?InnoDB:?Starting?recovery?for?XA?transactions...
100224?23:24:20?InnoDB:?Transaction?0?4497755?in?prepared?state?after?recovery
100224?23:24:20?InnoDB:?Transaction?contains?changes?to?8?rows
100224?23:24:20?InnoDB:?Transaction?0?4468551?in?prepared?state?after?recovery
100224?23:24:20?InnoDB:?Transaction?contains?changes?to?1?rows
100224?23:24:20?InnoDB:?Transaction?0?4468140?in?prepared?state?after?recovery
100224?23:24:20?InnoDB:?Transaction?contains?changes?to?1?rows
100224?23:24:20?InnoDB:?3?transactions?in?prepared?state?after?recovery
100224?23:24:20?[Note]?Found?3?prepared?transaction(s)?in?InnoDB
100224?23:24:20?[Warning]?Found?3?prepared?XA?transactions
100224?23:24:20?[Note]?Event?Scheduler:?Loaded?0?events
100224?23:24:20?[Note]?/opt/mysql/bin/mysqld:?ready?for?connections.
Version:?'8.0.18'?socket:?'/tmp/mysql.sock'?port:?3306?MySQL?Community?Server?(GPL)?

從上面的日志信息中，可以看出有三個XA的事務(wù)沒有提交或回滾。那該如何恢復(fù)MySQL的XA事務(wù)呢？

恢復(fù)MySQL XA事務(wù)

首先，登錄到MySQL，執(zhí)行如下命令。

mysql>?xa?recover;
+----------+--------------+--------------+------------------------------------------------------------+
|?formatID?|?gtrid_length?|?bqual_length?|?data?|
+----------+--------------+--------------+------------------------------------------------------------+
|?131075?|?30?|?28?|?1-7f000001:bae5:4b6928eb:f06397f000001:bae5:4b6928eb:f0650?|
|?131075?|?30?|?28?|?1-7f000001:bae5:4b6928eb:fb5c37f000001:bae5:4b6928eb:fb5cd?|
|?131075?|?30?|?28?|?1-7f000001:bae5:4b6928eb:f03ea7f000001:bae5:4b6928eb:f0400?|
+----------+--------------+--------------+------------------------------------------------------------+?

數(shù)據(jù)表示信息如下：

formatIDis?the?formatIDpart?of?the?transaction?xid
gtrid_lengthis?the?length?in?bytes?of?the?gtridpart?of?the?xid
bqual_lengthis?the?length?in?bytes?of?the?bqualpart?of?the?xid
datais?the?concatenation?of?the?gtridand?bqualparts?of?the?xid?

這是三個XA事務(wù)的信息，準備直接回滾。

mysql>?xa?rollback?'1-7f000001:bae5:4b6928eb:fb5c3','7f000001:bae5:4b6928eb:fb5cd',131075;
Query?OK,?0?rows?affected?(0.41?sec)?

MySQL XA事務(wù)補充

XA事務(wù)支持限于InnoDB存儲引擎。

MySQL ?XA實施是針對外部XA的，其中，MySQL服務(wù)器作為資源管理器，而客戶端程序作為事務(wù)管理器。未實施“內(nèi)部XA”。這樣，就允許MySQL服務(wù)器內(nèi)的單獨存儲引擎作為RM（資源管理器），而服務(wù)器本身作為TM（事務(wù)管理器）。處理包含1個以上存儲引擎的XA事務(wù)時，需要內(nèi)部XA。內(nèi)部XA的實施是不完整的，這是因為，它要求存儲引擎在表處理程序?qū)用嫔现С謨呻A段提交，目前僅對InnoDB實現(xiàn)了該特性。

對于XA START，不支持JOIN和RESUME子句。

對于XA END，不支持SUSPEND [FOR MIGRATE]子句。

在全局事務(wù)內(nèi)，對于每個XA事務(wù)，xid值的bqual部分應(yīng)是不同的，該要求是對當前MySQL XA實施的限制。它不是XA規(guī)范的組成部分。

如果XA事務(wù)達到PREPARED狀態(tài)而且MySQL服務(wù)器宕機，當服務(wù)器重啟后，能夠繼續(xù)處理事務(wù)。就像原本應(yīng)當?shù)哪菢?。但是，如果客戶端連接中止而服務(wù)器繼續(xù)運行，服務(wù)器將回滾任何未完成的XA事務(wù)，即使該事務(wù)已達到PREPARED狀態(tài)也同樣。它應(yīng)能提交或回滾PREPARED XA事務(wù)，但在不更改二進制日志機制的情況下不能這樣。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝