MySQL 5.7复制的一个小bug-XA事务

线上一个5.7从库复制中断：

查询具体报错：

第一感觉很奇怪，为什么会rollback失败呢？于是根据gtid去对应的主库binlog去看了下，并没有任何rollback语句：

看下本地的relay log，找到这个事务的gtid

到这里，这个relay log日志文件结束了。很显然问题也找到了，就是执行

出错了。

首先 我们看到 这个rollback是MySQL自己加上去的，那么为什么要加呢？

mysql为了保证一个事务只在一个binlog里，所以当Binlog或者relay log发生截断时，最后一个事务要么commit，要么rollback，如果rollback，那么下一个binlog或者relay log会把这个事务重做一遍，保证这个事务不会丢。

由于xa事务无法直接rollback，而需要xa rollback ‘XXX’，所以复制就停了。

怎么修复？是不是直接跳过这个rollback就行了？

我们来试一下，跳过这个rollback:

这里GTID_NEXT值不能用show slave status的里executed值，得用具体报错的停止的gtid

但是，show slave status看到，还是有报错：

为什么又报这个事务commit找不到XID呢？

之前说过，在relaylog截断的时候，如果事务没有commit,会自动在最后加rollback，在下一个relay log开始的时候重新做一次这个事务，按理说我们跳过这个rollback，在下个relaylog会被重做，为啥会在commit的时候找不到xid呢？

我们看到我们跳过的gtid原来就是重做这个事务到PREPARE阶段的gtid，原来，rollback是没有gtid的，所以我们实际上就是把这个事务到PREPARE阶段的gtid给跳过了，commit的时候肯定会找不到xid，接着怎么修复？

为什么这是5.7的一个bug呢？5.7之前的版本因为relaylog被截断并不会出现这个bug。

5.7对xa事务的binlog记录方式做了修改，把 xa start,xa end,xa prepare放到一个event里，xa commit又是另外一个event。而在之前的MySQL版本中，整个xa事务从start到commit都是在一个event中，所以其他版本并没有问题。

最后一个问题：5.7为啥要把xa事务拆成两个event？简单的讲是为了数据安全性。

5.5或者5.6假设下面一个场景：

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

正因为5.7之前版本的xa事务存在这个bug，5.7后做了修复。从XA START到XA PREPARE之间的 *** 作都被记录到了Master的Binlog中，然后通过复制关系传到了Slave上。也就是说5.7开始，MySQL对于XA事务，在prepare的时候就完成了写Binlog的 *** 作，通过新增一种叫 XA_prepare_log_event 的event类型来实现。

其实 MySQL5.7在xa事务上远不止这个bug，后面再来慢慢总结。

在主服务器上建立一个为从服务器进行复制使用的用户。该账户必须授予 REPLICATION SLAVE 权限，由于仅仅是进行复制使用所以不需要再授予任何其它权限。

mysql>GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%'192.168.0.2' IDENTIFIED BY 'slavepasswd'

mysql>FLUSH PRIVILEGES

3、编辑主服务器的配置文件：/etc/my.cnf的[ mysqld ] 部分：

server-id = 本机数据库 ID 标示，该部分还应有一个server-id=Master_id选项，其中master_id必须为1到232之间的一个正整数值

log-bin = 二进制日志的位置和名称

binlog-do-db = 需要备份的数据库名，如果备份多个数据库，重复设置这个选项即可

binlog-ignore-db = 不需要备份的数据库苦命，如果备份多个数据库，重复设置这个选项即可

---