背景描述

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

现象

查询innodb_trx表，发现有两个事务处于运行中。
SELECT * from information_schema.INNODB_TRX;

图片发自简书App

尝试解决

1. 方案1--杀进程---行不通
   网上资料都是说按照trx_mysql_thread_id找到对应进程杀掉，但我这里是0，没有进程id，没法杀，而且它是重启mysql服务后自动就运行的两个事务。这个方案的本质是要找到事务的发起者,然后通过发起者停掉事务，但我们这个问题中事务发起者未知。

2.方案2--xa rollback--不起作用
还有资料说，通过xarecover查看当前xa事务，然后回滚或提交。

image.png

xa ROLLBACK 'globalid','branch-2';
xa ROLLBACK 'globalid','branch-1';

image.png

image.png

image.png

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

xa COMMIT 'globalid','branch-2';
xa COMMIT 'globalid','branch-1';

image.png

问题分析

通过重启mysql后事务依然存在,我们大概推断应该跟redoundo有关系，xa事务异常后，mysql服务重启检测到了这两个事务就自动运行了，但因为未知原因，这两个事务并没有执行，一直处于running状态。
曾经试图研究mysql的redo undo机制或者对应的文件格式，但时间关系没有深入。
尝试能否打开对应的redo文件，对里面的语句进行修改，但网上找了资料没有合适的工具可以做这个事情。
一直很苦恼的思索解决办法，也咨询身边的一些朋友，对没有遇到过这方面的问题。

可行的解决方案

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

image.png

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

image.png

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