作者个人研发的在高并发场景下,提供的简单、稳定、可扩展的延迟消息队列框架,具有精准的定时任务和延迟队列处理功能。自开源半年多以来,已成功为十几家中小型企业提供了精准定时调度方案,经受住了生产环境的考验。为使更多童鞋受益,现给出开源框架地址:
https://github.com/sunshinelyz/mykit-delay
PS: 欢迎各位Star源码,也可以pr你牛逼哄哄的代码。
前段时间搭建了一套MySQL分布式数据库集群,数据库节点有12个,用来测试各种分布式事务方案的性能和优缺点。测试MySQL XA事务时,正当测试脚本向数据库中批量插入数据时,强制服务器断电!注意:是直接拔电源,使其瞬间断电,再次重启服务器后,MySQL数据库报错了。特此记录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,执行如下命令。
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)
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事务,但在不更改二进制日志机制的情况下不能这样。