1.1. 关于

MySQL XA 事务通常用于分布式事务处理当中。比如在分库分表的场景下，当遇到一个用户事务跨了多个分区，需要使用XA事务来完成整个事务的正确的提交和回滚，即保证全局事务的一致性。

1.2. XA 事务在分库分表场景的使用

下图是个典型的分库分表场景，前端是一个Proxy后面带若干个MySQL实例，每个实例是一个分区。

假设一个表test定义如下，Proxy根据主键”a”算Hash决定一条记录应该分布在哪个节点上：

create table test(a int primay key, b int) engine = innodb;

应用发到Proxy的一个事务如下：

begin;
insert into test values (1, 1);
update test set b = 1 where a = 10;
commit;

Proxy收到这个事务需要将它转成XA事务发送到后端的数据库以保证这个事务能够安全的提交或回滚，一般的Proxy的处理步骤如下：

Proxy先收到begin，它只需要设置一下自己的状态不需要向后端数据库发送
当收到 insert 语句时Proxy会解析语句，根据“a”的值计算出该条记录应该位于哪个节点上，这里假设是“分库1”
Proxy就会向分库1上发送语句xa start ‘xid1’，开启一个XA事务，这里xid1是Proxy自动生成的一个全局事务ID；同时原来的insert语句insert into values(1,1)也会一并发送到分库1上。
这时Proxy遇到了update语句，Proxy会解析 where条件主键的值来决定该条语句会被发送到哪个节点上，这里假设是“分库2”
Proxy就会向分库2上发送语句xa start ‘xid1’，开启一个XA事务，这里xid1是Proxy之前已经生成的一个全局事务ID；同时原来的update语句update test set b = 1 where a = 10也会一并发送到分库2上。
最后当Proxy解析到commit语句时，就知道一个用户事务已经结束了，就开启提交流程
Proxy会向分库1和分库2发送 xa end ‘xid1’;xa prepare ‘xid1’语句，当收到执行都成功回复后，则继续进行到下一步，如果任何一个分库返回失败，则向分库1和分库2 发送 xa rollback ‘xid1’，回滚整个事务
当 xa prepare ‘xid1’都返回成功，那么 proxy会向分库1和分库2上发送 xa commit ‘xid1’，来最终提交事务。

这里有一个可能的优化，即在步骤4时如果Proxy计算出update语句发送的节点仍然是“分库1”时，在遇到commit时，由于只涉及到一个分库，它可以直接向“分库1”发送 xa end ‘xid1’; xa commit ‘xid1’ one phase来直接提交该事务，避免走 prepare阶段来提高效率。

1.3. XA对事务安全的影响分析

从以上分库分表场景下分布式事务的处理过程来看，整个分布式事务的安全性依赖是XA Prepare了的事务的可靠性，也就是在数据库节点上 XA Prepare了的事务必须是持久化了的，这样当XA Commit发来时才可以提交。设想如下场景：

Proxy已经向分库1和分库2上发送完了 xa prepare ‘xid1’语句，并得到了成功的回复
Proxy向分库1上发送了 ‘xa commit ‘xid1’语句，并已经成功返回
当 Proxy向分库2上发送 ‘xa commit ‘xid1’时，网络断开了，或者分库2的数据库实例被kill了
当网络恢复（这时相关的Session已经退出了）或数据库实例再启动后（或切换到备库），XA prepare了的事务已经回滚了，当Proxy XA commit ‘xid1’发过来后数据库实例根本找不到xid1这个xa事务

上面的过程就导致了分布式事务的不一致：分库1提交了事务，分库2回滚了事务，整个事务提交了一半，回滚了一半。

在MySQL 5.6中以上过程是可能发生的，因为xa prepare并没有严格的持久化，当Session断开，数据库崩溃等情况下这些事务会被回滚掉，而且的当一个主库配置了SemiSync的备库时xa prepare了的事务也不会被发送的备库，如果主库切换到备库这些事务也会丢失。

1.4. MySQL 5.7 XA可靠性改进

MySQL 5.7解决了 xa prepare了的事务的严格持久化问题，也就是在session断开和实例崩溃重启情况下这些事务不丢，同时在 xa prepare ‘xid1’返回之前XA事务也会同步到备库。下面将通过在5.6和5.7上分别执行xa prepare并对binlog event进行分析来演示这个改进。

1.5. 断开连接对xa prepare的事务影响

在5.6和5.7上分别执行如下sql然后断开连接，再重新连接使用的xa recover验证 XA 事务是否回滚了。

xa start 'xid1';
insert into test values(1, 1);
xa end 'xid1';
xa prepare 'xid1';
-- 这里断开再连上新连接执行 xa recover

在 5.6 的版本上将返回空的结果，在 5.7 的版本上返回：

mysql> xa recover;
+----------+--------------+--------------+------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+------+
|        1 |            4 |            0 | xid1 |
+----------+--------------+--------------+------+
1 row in set (0.00 sec)

说明断开连接后 5.7的prepare了的xa事务没有丢失。

1.6. XA 事务的 Binlog events 异同

在5.6和5.7上分别执行如下事务，然后用 show binlog events 查看两者binlog的不同：

xa start 'xid1';
insert into test values(1, 1);
xa end 'xid1';
xa prepare 'xid1';
xa commit 'xid1';

5.6的结果：

mysql-bin.000001 | 304 | Gtid           |      3706 |         352 | SET @@SESSION.GTID_NEXT= 'uuid:2'
mysql-bin.000001 | 352 | Query          |      3706 |         424 | BEGIN
mysql-bin.000001 | 424 | Table_map      |      3706 |         472 | table_id: 71 (test.test)
mysql-bin.000001 | 472 | Write_rows     |      3706 |         516 | table_id: 71 flags: STMT_END_F
mysql-bin.000001 | 516 | Query          |      3706 |         589 | COMMIT

5.7的结果：

mysql-bin.000001 |  544 | Gtid           |      3707 |         592 | SET @@SESSION.GTID_NEXT= 'uuid:3'
mysql-bin.000001 |  592 | Query          |      3707 |         685 | XA START X'78696431',X'',1
mysql-bin.000001 |  685 | Table_map      |      3707 |         730 | table_id: 74 (test.t) 
mysql-bin.000001 |  730 | Write_rows     |      3707 |         774 | table_id: 74 flags: STMT_END_F
mysql-bin.000001 |  774 | Query          |      3707 |         865 | XA END X'78696431',X'',1 
mysql-bin.000001 |  865 | XA_prepare     |      3707 |         905 | XA PREPARE X'78696431',X'',1
mysql-bin.000001 |  905 | Gtid           |      3707 |         953 | SET @@SESSION.GTID_NEXT= 'uuid:4' |
mysql-bin.000001 |  953 | Query          |      3707 |        1047 | XA COMMIT X'78696431',X'',1

可以看到 MySQL 5.6 XA 事务和普通事务的binlog是一样的，并没有体现 xa prepare。而到了 MySQL 5.7 XA 事务的binlog和普通的事务是完全不同的，XA Prepare有单独的Log event类型，有自己的Gtid，当开启semi-sync的情况下，MySQL 5.7 执行 XA prepare 时会等备库回复后才返回结果给客户端，这样XA prepare执行完就是安全的。

1.7. 这个是重点

在MySQL 5.7.7 之前，MySQL一直存在一个"bug"。在事务达到PREPARED状态后，客户端断开与MySQL的连接，MySQL 会自动回滚该事务，这个行为不符合分布式事务的规范，MySQL将PREPARED的事务丢失了。之所以MySQL这么实现是因为MySQL 5.7.7 之前PREPARED的事务并不会记录到binlog中。客户端退出后会丢失该信息，如果允许再提交，那么binlog缺少事务信息，会造成主从不一致。

在MySQL 5.7.7 之后，MySQL 新增了一个XA_prepare_log_event的事件，会把xa start到xa prepare中间的操作记录到Binlog中。Slave读取Relay log 进行回放，当SQL Thread读取到PREPARED的事务后，在读取xa commit或者xa rollback前，会进行一个类似客户端断开的操作，继续读取后续的事务信息，不会阻塞SQL Thread的执行。从以上的结果看，Oracle在MySQL 5.7.7 上确实完美的解决了MySQL XA一直存在的一个"bug"。

以上摘自:

MySQL XA 介绍

MySQL · 特性分析 · 浅谈 MySQL 5.7 XA 事务改进

XA协议