本篇文章主要介绍了"mysql之分布式事务"，主要涉及到方面的内容，对于MySql感兴趣的同学可以参考一下：
分布式事务通常采用2PC协议，全称Two Phase Commitment Protocol。该协议主要为了解决在分布式数据库场景下，所有节点间数据一致性的问题...
mysql>
XA START 'mysql57';
mysql>
INSERTINTOt VALUES(1,1);
mysql>
XA END'mysql57';
mysql>
XA PREPARE'mysql57'
| 这个时候，我们通过mysqlbinlog来查看下Master上的Binlog，结果如下：
同时也对比下Slave上的Relay log，如下：
通过上面的操作，明显发现在prepare以后，从XA START到XA PREPARE之间的操作都被记录到了Master的Binlog中，然后通过复制关系传到了Slave上。也就是说MySQL-5.7开始，MySQL对于分布式事务，在prepare的时候就完成了写Binlog的操作，通过新增一种叫XA_prepare_log_event的event类型来实现，这是与以前版本的主要区别(以前版本prepare时不写Binlog)
当然仅靠这一点是不够的，因为我们知道Slave通过SQL thread来回放Relay log信息，由于prepare的事务能阻塞整个session，而回放的SQL thread只有一个(不考虑并行回放)，那么SQL thread会不会因为被分布式事务的prepare阶段所阻塞，从而造成整个SQL thread回放出现问题？这也正是官方要解决的第二个问题：怎么样能使SQL thread在回放到分布式事务的prepare阶段时，不阻塞后面event的回放？其实这个实现也很简单(在xa.cc::applier_reset_xa_trans)，只要在SQL
thread回放到prepare的时候，进行类似于客户端断开连接的处理即可(把相关cache与SQL thread的连接句柄脱离)。最后在Slave服务器上，用户通过命令XA RECOVER可以查到如下信息：
1 2 3 4 5 6 | mysql>
XA RECOVER;
+----------+--------------+--------------+---------+
|
formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+---------+
|
