MySQL 5.7的分布式事务支持举例分析

本文主要讲解“MySQL 5.7中分布式事务支持的实例分析”。感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“MySQL 5.7中分布式事务支持的实例分析”！

分布式事务通常采用2PC协议，称为两阶段提交协议。该协议主要解决分布式数据库场景中各节点之间的数据一致性问题。在分布式事务环境下，事务的提交会变得相对复杂，由于多个节点的存在，部分节点可能无法提交，即需要在每个数据库实例中保证事务的ACID特性。总之，在分布式提交中，只要一个节点提交失败，所有节点都不能提交，只有当所有节点都可以提交时，整个分布式事务才能提交。

分布式事务通过2PC协议将提交分为两个阶段。

准备；

提交/回滚

prepare的第一阶段只是用来询问各个节点是否可以提交事务，提交的第二阶段只有在所有节点都有“权限”的情况下才能进行，否则就是回滚。应该注意的是，所有成功准备的交易都必须提交。

MySQL分布式事务

一直以来，MySQL数据库都支持分布式事务，但只能说支持有限，具体体现在：

当客户端退出或服务关闭时，准备事务将回滚。

服务器故障重启提交后，相应的Binlog丢失。

上述问题在MySQL数据库中存在了几十年，直到MySQL-5.7.7才被官方修复。虽然InnoSQL在5.5版本已经修复了，但是和官方的修复方案相比，我们真的没有做得那么优雅。下面将详细介绍这个问题的具体表现形式和官方修复方法，并使用官方的MySQL-5.6.27版本(未修复)和MySQL-5.7.9版本(已修复)进行验证。

先看看存在的问题。让我们创建一个如下所示的表：

createtablet(

idintauto_incrementprimarykey，

空军情报

)engine=innodb

对于上表，通过以下操作插入数据：

mysqlXASTART 'mysql56

mysqlINSERTINTOtVALUES(1，1)；

mysqlXAEND 'mysql56

mysqlXAPREPARE'mysql56 '

通过上面的操作，用户创建了一个分布式事务，并且prepare没有返回错误，表示分布式事务可以提交。使用XARKER命令查看时会显示以下结果：

mysqlXARECOVER

- - - -

| format id | gtrid _ length | bq ual _ length | data |

- - - -

|1|7|0|mysql56|

- - - -

此时，如果用户在退出客户端后重新连接，他将通过命令xa recover发现刚刚创建的2PC事务丢失。也就是说，准备成功的交易丢失，不符合2PC协议规范！

出现上述问题的主要原因是MySQL-5.6在客户端退出时会自动回滚prepare事务，那么MySQL为什么要这样做呢？这主要取决于MySQL的内部实现，版本在MySQL-5.7之前，为prepa

re的事务，MySQL是不会记录binlog的(官方说是减少fsync，起到了优化的作用)。只有当分布式事务提交的时候才会把前面的操作写入binlog信息，所以对于binlog来说，分布式事务与普通的事务没有区别，而prepare以前的操作信息都保存在连接的IO_CACHE中，如果这个时候客户端退出了，以前的binlog信息都会被丢失，再次重连后允许提交的话，会造成Binlog丢失，从而造成主从数据的不一致，所以官方在客户端退出的时候直接把已经prepare的事务都回滚了！

官方的做法，貌似干得很漂亮，牺牲了一点标准化的东西，至少保证了主从数据的一致性。但其实不然，若用户已经prepare后在客户端退出之前，MySQL发生了宕机，这个时候又会怎样？

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

以上是MySQL-5.7以前版本MySQL在分布式事务上的各种问题，那么MySQL-5.7版本官方做了哪些改进？这个可以从官方的WL#6860描述上得到一些信息，我们还是本着没有实践就没有发言权的态度，从具体的操作上来分析下MySQL-5.7的改进方法：

还是以上面同样的表结构进行同样的操作如下：

mysql> XA START 'mysql57';
mysql> INSERT INTO t VALUES(1,1);
mysql> XA END 'mysql57';
mysql> XA PREPARE 'mysql57'通过上面的操作，明显发现在prepare以后，从XA START到XA PREPARE之间的操作都被记录到了Master的Binlog中，然后通过复制关系传到了Slave上。也就是说MySQL-5.7开始，MySQL对于分布式事务，在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可以查到如下信息：

mysql> XA RECOVER;
+----------+--------------+--------------+---------+
| formatID | gtrid_length | bqual_length | data    |
+----------+--------------+--------------+---------+
| 1        | 7            | 0            | mysql57 |
+----------+--------------+--------------+---------+

至于上面的事务什么时候提交，一般等到Master上进行XA COMMIT  ‘mysql57’后，slave上也同时会被提交。

到此，相信大家对“MySQL 5.7的分布式事务支持举例分析”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！