Mysql Transaction Recovery Process _mysql

MySQL database power-on error：
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 is 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 is in the XA prepared state.
Innodb:transaction 0 4468551 is in the XA prepared state.
Innodb:transaction 0 4468140 is in the XA prepared state.
Innodb:3 transaction (s) which must is 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 and 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)
means that there are three XA transactions that are not committed or rolled back.
log on to 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 |
+----------+--------------+--------------+------------------------------------------------------------+
Data representation information is as follows：
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
This is information for three XA transactions and is ready to be rolled back directly.
mysql> xa rollback ' 1-7f000001:bae5:4b6928eb:fb5c3 ', ' 7f000001:bae5:4b6928eb:fb5cd ', 131075;
Query OK, 0 rows affected (0.41 sec)
It's normal to start again.

MySQL XA
I.5. Restrictions on XA transactions
XA transaction support is limited to INNODB storage engines.
MySQL XA implementations are for external XA, where the MySQL server acts as a resource manager, and the client program acts as the transaction manager. "Internal XA" is not implemented. This allows a separate storage engine within the MySQL server as RM (Resource Manager) and the server itself as a TM (transaction manager). Internal XA is required to handle XA transactions that contain more than 1 storage engines. The implementation of internal XA is incomplete because it requires the storage engine to support two-phase commits at the table handler level, which is currently implemented only for InnoDB.
For XA START, join and resume clauses are not supported.

For the XA end, the suspend [for MIGRATE] clause is not supported.
Within a global transaction, the bqual portion of the XID value should be different for each XA transaction, which is a restriction on the current MySQL XA implementation. It is not part of the XA specification.

If the XA transaction reaches the prepared state and the MySQL server is down, the server can continue to process the transaction after it restarts. As it should have been. However, if the client connection is aborted and the server continues to run, the server rolls back any outstanding XA transactions, even if the transaction has reached the prepared state. It should be able to commit or rollback prepared XA transactions, but this cannot happen without changing the binary log mechanism.