写在后面
前段时间搭建了一套 MySQL 分布式数据库集群，数据库节点有 12 个，用来测试各种分布式事务计划的性能和优缺点。测试 MySQL XA 事务时，正当测试脚本向数据库中批量插入数据时，强制服务器断电！留神：是间接拔电源，使其霎时断电，再次重启服务器后，MySQL 数据库报错了。特此记录 MySQL XA 事务的复原。
MySQL XA 事务问题
服务器强制断电后重启，此时 MySQL 报错，查看 MySQL 启动日志时，发现如下所示的错误信息。
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 的事务没有提交或回滚。那该如何复原 MySQL 的 XA 事务呢？
复原 MySQL 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 事务补充
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 事务，但在不更改二进制日志机制的状况下不能这样。
重磅福利
微信搜一搜【冰河技术】微信公众号，关注这个有深度的程序员，每天浏览超硬核技术干货，公众号内回复【PDF】有我筹备的一线大厂面试材料和我原创的超硬核 PDF 技术文档，以及我为大家精心筹备的多套简历模板（不断更新中），心愿大家都能找到心仪的工作，学习是一条时而郁郁寡欢，时而开怀大笑的路，加油。如果你通过致力胜利进入到了心仪的公司，肯定不要懈怠放松，职场成长和新技术学习一样，逆水行舟。如果有幸咱们江湖再见！
另外，我开源的各个 PDF，后续我都会继续更新和保护，感激大家长期以来对冰河的反对！！
写在最初
如果你感觉冰河写的还不错，请微信搜寻并关注「冰河技术 」微信公众号，跟冰河学习高并发、分布式、微服务、大数据、互联网和云原生技术，「 冰河技术 」微信公众号更新了大量技术专题，每一篇技术文章干货满满！不少读者曾经通过浏览「 冰河技术 」微信公众号文章，吊打面试官，胜利跳槽到大厂；也有不少读者实现了技术上的飞跃，成为公司的技术骨干！如果你也想像他们一样晋升本人的能力，实现技术能力的飞跃，进大厂，升职加薪，那就关注「 冰河技术」微信公众号吧，每天更新超硬核技术干货，让你对如何晋升技术能力不再迷茫！