MySQL · 特性分析 · MySQL 5.7 外部XA Replication实现及缺陷分析

MySQL 5.7增强了分布式事务的支持，解决了之前客户端退出或者服务器关闭后prepared的事务回滚和服务器宕机后binlog丢失的情况。

为了解决之前的问题，MySQL5.7将外部XA在binlog中的记录分成了两部分，使用两个GTID来记录。执行prepare的时候就记录一次binlog，执行commit/rollback再记录一次。由于XA是分成两部分记录，那么XA事务在binlog中就可能是交叉出现的。Slave端的SQL线程在apply的时候需要能够在这些不同事务间切换。

但MySQL XA Replication的实现只考虑了Innodb一种事务引擎的情况，当添加其他事务引擎的时候，原本的一些代码逻辑就会有问题。同时MySQL源码中也存在宕机导致主备不一致的缺陷。

当执行 XA START ‘xid’后，内部xa_state进入XA_ACTIVE状态。

第一次记录DML操作的时候，通过下面代码可以看到，对普通事务在binlog的cache中第一个event记录’BEGIN’,如果是xa_state处于XA_ACTIVE状态就记录’XA START xid’，xid为序列化后的。

XA END xid的执行会将xa_state设置为XA_IDLE。

当XA PREPARE xid执行的时候，binlog_prepare会通过检查thd的xa_state是否处于XA_IDLE状态来决定是否记录binlog。如果在对应状态，就会调用MYSQL_BINLOG的commit函数，记录’XA PREPARE xid’，将之前cache的binlog写入到文件。

当XA COMMIT/ROLLBACK xid执行时候，调用do_binlog_xa_commit_rollback记录’XA COMMIT/ROLLBACK xid’。

由于XA PREPARE单独记录binlog，那么binlog中的events一个xa事务就可能是分隔开的。举个例子，session1中xid为’a’的分布式事务执行xa prepare后，session2中执行并提交了xid为’z’的事务，然后xid ‘a’才提交。我们可以看到binlog events中xid ‘z’的events在’a’的prepare和commit之间。

由于XA事务在binlog中是会交叉出现的，Slave的SQL线程如果按照原本普通事务的方式重放，那么就会出现SQL线程中还存在处于prepared状态的事务，就开始处理下一个事务了，锁状态、事务状态等会错乱。所以SQL线程需要能够支持这种情况下不同事务间的切换。

SQL线程要做到能够在执行XA事务时切换到不同事务，需要做到server层保留原有xid的Transaction_ctx信息，引擎层也保留原有xid的事务信息。

server层保留原有xid的Transaction_ctx信息是通过在prepare的时候将thd中xid的Transaction_ctx信息从transacion_cache中detach掉，创建新的保留了XA事务信息的Transaction_ctx放入transaction_cache中。

引擎层的实现并不是通过在prepare的时候创建新trx_t的来保存原有事务信息。而是在XA START的时候将原来thd中所有的engine ha_data单独保留起来，为XA事务创建新的。在XA PREPARE的时候，再将原来的reattach回来，将XA的从thd detach掉，解除XA和thd的关联。引擎层添加了新的接口replace_native_transaction_in_thd来支持上述操作。对于Slave的SQL线程，函数调用如下：

当XA COMMIT/ROLLBACK执行的时候，如果当前thd中没有对应的xid，就会从transaction_cache中查找对应xid的state信息，然后调用各个引擎的commit_by_xid/rollback_by_xid接口提交/回滚XA事务。

由于XA COMMIT/XA ROLLBACK是单独作为一部分，这部分并没有原来XA事务涉及到库、表的信息，所以XA COMMIT在Slave端当slave-parallel-type为DATABASE时是无法并发执行的，在slave端强制设置mts_accessed_dbs为OVER_MAX_DBS_IN_EVENT_MTS使其串行执行。

MySQL中普通事务提交的时候，需要先在引擎中prepare，然后再写binlog，之后再做引擎commit。但在MySQL执行XA PREPARE的时候先写入了binlog，然后才做引擎的prepare。如果引擎在做prepare的时候失败或者服务器crash就会导致binlog和引擎不一致，主备进入不一致的状态。

在MySQL5.7中对模拟simulate_xa_failure_prepare的DEBUG情况做如下修改，使之模拟在Innodb引擎prepare的时候失败。

然后运行下面的case，可以看到Master上的XA失败后被回滚。但由于这个时候已经写入了binlog events，导致Slave端执行了XA事务，留下一个处于prepared状态的XA事务。

在MySQL5.7源码中，如果在binlog和InnoDB引擎都prepare之后是不是数据就安全了呢？我们在ha_prepare函数中while循环调用完所有引擎prepare函数之后添加如下DEBUG代码，可以控制在prepare调用结束后服务器crash掉。

然后跑下面的testcase。可以看到即使所有引擎都prepare了，宕机重启后XA RECOVER还是还是没有能够找回之前prepare的事务。而且这个时候我们查看binlog文件可以看到binlog已经写成功，这也会导致主备不一致。很明显，应该是InnoDB引擎丢失了prepare的日志。那么是什么原因导致这个问题？感兴趣的同学可以查看int MYSQL_BIN_LOG::ordered_commit(THD *thd, bool all, bool skip_commit)和innobase中trx_prepare的代码，看process_flush_stage_queue和flush_logs和thd->durability_property的相关逻辑。这里不再展开详细叙述。

上面两个问题的修复，都可以通过先执行事务引擎的prepare操作，再调用binlog的prepare来解决。

在上面实现分析中可以看到Slave在执行XA START的时候，由于这个时候并不知道该XA事务涉及到哪些引擎，所以对所有Storage engine引擎都调用了detach_native_trx。但在XA PREPARE的时候，源码中只对XA涉及到的引擎调用了reattach_engine_ha_data_to_thd。对于引擎可插拔的MySQL来说，当server中不止一个事务引擎，这里就会存在有的引擎原thd中的trx被detach后没有被reattach。

我们可以拿支持tokudb的percona server做对应实验。对DEBUG编译的server，执行下面replication的testcase。该case对TokuDB做一个完整的XA事务后，再向Innodb写入。运行该case，slave端会产生assert_fail的错误。因为TokuDB执行XA事务时，将Innodb的ha_data放入backup，但由于Innodb没有参与该XA事务，所以并没有reattach，导致gdb可以看到assert_fail处InnoDB的ha_ptr_backup不为NULL，不符合预期。

修复问题，可以在需要reattach_engine_ha_data_to_thd的代码处，对所有storage engine再次调用该操作。

对于不支持reattach_engine_ha_data_to_thd的事务引擎实际是不支持重放MySQL5.7新XA方式生成的binlog的，但在源码中并没有合适禁止操作。这就会导致slave在apply的时候数据错乱。

继续使用支持tokudb的percona server做实验。由于TokuDB并没有实现reattach_engine_ha_data_to_thd接口，Slave在重放XA事务的时候，在TokuDB引擎中实际就在原本关联thd的trx上操作，并没有生成新的trx。这就会导致数据等信息错乱，可以看到下面的例子。session1做了一个XA事务，插入数值1，prepare后并没有提交。随后另一个session插入数值2，但在slave同步后，数值2无法查询到。在session1提交了XA事务，写入TokuDB的数值1、2才在slave端查询到。

修复该问题，需要对没有实现新接口的事务引擎在执行XA时候给与合适的禁止操作，同时需要支持新XA的事务引擎要实现reattach_engine_ha_data_to_thd接口。