MySQL 5.7复制的一个小bug-XA事务

MySQL 5.7复制的一个小bug-XA事务,第1张

线上一个5.7从库复制中断:

查询具体报错:

第一感觉很奇怪,为什么会rollback失败呢?于是根据gtid去对应的主库binlog去看了下,并没有任何rollback语句:

看下本地的relay log,找到这个事务的gtid

到这里,这个relay log日志文件结束了。很显然问题也找到了,就是执行

出错了。

首先 我们看到 这个rollback是MySQL自己加上去的,那么为什么要加呢?

mysql为了保证一个事务只在一个binlog里,所以当Binlog或者relay log发生截断时,最后一个事务要么commit,要么rollback,如果rollback,那么下一个binlog或者relay log会把这个事务重做一遍,保证这个事务不会丢。

由于xa事务无法直接rollback,而需要xa rollback ‘XXX’,所以复制就停了。

怎么修复?是不是直接跳过这个rollback就行了?

我们来试一下,跳过这个rollback:

这里GTID_NEXT值不能用show slave status的里executed值,得用具体报错的停止的gtid

但是,show slave status看到,还是有报错:

为什么又报这个事务commit找不到XID呢?

之前说过,在relaylog截断的时候,如果事务没有commit,会自动在最后加rollback,在下一个relay log开始的时候重新做一次这个事务,按理说我们跳过这个rollback,在下个relaylog会被重做,为啥会在commit的时候找不到xid呢?

我们看到我们跳过的gtid原来就是重做这个事务到PREPARE阶段的gtid,原来,rollback是没有gtid的,所以我们实际上就是把这个事务到PREPARE阶段的gtid给跳过了,commit的时候肯定会找不到xid,接着怎么修复?

为什么这是5.7的一个bug呢?5.7之前的版本因为relaylog被截断并不会出现这个bug。

5.7对xa事务的binlog记录方式做了修改,把 xa start,xa end,xa prepare放到一个event里,xa commit又是另外一个event。而在之前的MySQL版本中,整个xa事务从start到commit都是在一个event中,所以其他版本并没有问题。

最后一个问题:5.7为啥要把xa事务拆成两个event?简单的讲是为了数据安全性。

5.5或者5.6假设下面一个场景:

MySQL在某个分布式事务prepare成功后宕机,宕机前 *** 作该事务的连接并没有断开(如果在宕机前断开连接,事务会被MySQL自动回滚),这个时候已经prepare的事务并不会被回滚,所以在MySQL重新启动后,引擎层通过recover机制能恢复该事务。当然该事务的Binlog已经在宕机过程中被丢失,这个时候,如果去提交,则会造成主从数据的不一致, 即提交没有记录Binlog,从上丢失该条数据。

正因为5.7之前版本的xa事务存在这个bug,5.7后做了修复。从XA START到XA PREPARE之间的 *** 作都被记录到了Master的Binlog中,然后通过复制关系传到了Slave上。也就是说5.7开始,MySQL对于XA事务,在prepare的时候就完成了写Binlog的 *** 作,通过新增一种叫 XA_prepare_log_event 的event类型来实现。

其实 MySQL5.7在xa事务上远不止这个bug,后面再来慢慢总结。

使用xa进行测试时,对mysql进行了一些xa各阶段锁定试验,后来出现卡死情况就杀掉了线程,重启了mysql服务。重启后发现插入、修改数据都正常,但无法修改表结构,修改表结构就处于卡死状态,过一分多钟报超时错误。多次重启mysql服务后,问题依然如故.

查询innodb_trx表,发现有两个事务处于运行中。

SELECT * from information_schema.INNODB_TRX

2.方案2--xa rollback--不起作用

还有资料说,通过 xarecover 查看当前xa事务,然后回滚或提交。

针对上面的xa rollback我们也可以尝试用xa commit,问题一样不能解决(需要再次重启mysql才能运行,否则会找不到对应的xid)。

通过重启mysql后事务依然存在,我们大概推断应该跟redoundo有关系,xa事务异常后,mysql服务重启检测到了这两个事务就自动运行了,但因为未知原因,这两个事务并没有执行,一直处于running状态。

曾经试图研究mysql的redo undo机制或者对应的文件格式,但时间关系没有深入。

尝试能否打开对应的redo文件,对里面的语句进行修改,但网上找了资料没有合适的工具可以做这个事情。

一直很苦恼的思索解决办法,也咨询身边的一些朋友,对没有遇到过这方面的问题。

今天灵机一动,奔着大不了重新安装mysql的心态进行了破坏性的探索,当然前提要提前把数据备份出来。尝试停止mysql服务后,将mysql对应的datadir目录下几个文件删除掉,对应文件见下图。

然后重启mysql服务,曾担心启动失败的,但没想到mysql顺利的启动成功了,然后查看对应的表,发现一只running的事务终于消失了。

后续有时间我会继续深入分析其中的原理。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7344530.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-04
下一篇 2023-04-04

发表评论

登录后才能评论

评论列表(0条)

保存