mysql的XA事務恢復進程詳解。本站提示廣大學習愛好者：（mysql的XA事務恢復進程詳解）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql的XA事務恢復進程詳解正文
mysql數據庫開機報錯：
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
100224 12: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 12:24:20 InnoDB: Rollback of non-prepared transactions completed
100224 12:24:20 InnoDB: Started; log sequence number 0 3805002509
100224 12:24:20 InnoDB: Starting recovery for XA transactions...
100224 12:24:20 InnoDB: Transaction 0 4497755 in prepared state after recovery
100224 12:24:20 InnoDB: Transaction contains changes to 8 rows
100224 12:24:20 InnoDB: Transaction 0 4468551 in prepared state after recovery
100224 12:24:20 InnoDB: Transaction contains changes to 1 rows
100224 12:24:20 InnoDB: Transaction 0 4468140 in prepared state after recovery
100224 12:24:20 InnoDB: Transaction contains changes to 1 rows
100224 12:24:20 InnoDB: 3 transactions in prepared state after recovery
100224 12:24:20 [Note] Found 3 prepared transaction(s) in InnoDB
100224 12:24:20 [Warning] Found 3 prepared XA transactions
100224 12:24:20 [Note] Event Scheduler: Loaded 0 events
100224 12:24:20 [Note] /opt/mysql/bin/mysqld: ready for connections.
Version: '5.1.39' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
意味著有三個XA的事務沒有提交或回滾。
登錄到mysql
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 |
+----------+--------------+--------------+------------------------------------------------------------+
數據表現信息以下：
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事務的信息，預備直接回滾。
mysql> xa rollback '1-7f000001:bae5:4b6928eb:fb5c3','7f000001:bae5:4b6928eb:fb5cd',131075;
Query OK, 0 rows affected (0.41 sec)
再啟動就正常了。
MySQL XA
I.5. 對XA事務的限制
XA事務支撐限於InnoDB存儲引擎。
MySQL XA實行是針對內部XA的，個中，MySQL辦事器作為資本治理器，而客戶端法式作為事務治理器。未實行“外部XA”。如許，就許可MySQL辦事器內的零丁存儲引擎作為RM（資本治理器），而辦事器自己作為TM（事務治理器）。處置包括1個以上存儲引擎的XA事務時，須要外部XA。外部XA的實行是不完全的，這是由於，它請求存儲引擎在表處置法式層面上支撐兩階段提交，今朝僅對InnoDB完成了該特征。
關於XA START，不支撐JOIN和RESUME子句。
關於XA END，不支撐SUSPEND [FOR MIGRATE]子句。
在全局事務內，關於每一個XA事務，xid值的bqual部門應是分歧的，該請求是對以後MySQL XA實行的限制。它不是XA標准的構成部門。
假如XA事務到達PREPARED狀況並且MySQL辦事器宕機，當辦事重視啟後，可以或許持續處置事務。就像本來應該的那樣。然則，假如客戶端銜接中斷而辦事器持續運轉，辦事器將回滾任何未完成的XA事務，即便該事務已到達PREPARED狀況也異樣。它應能提交或回滾PREPARED XA事務，但在不更改二進制日記機制的情形下不克不及如許。
