双中心建设期间，xxx机房内部分mysql备库出现复制出错现象，所有出错信息一致，错误信息如下：

具体出错原因：

从以上信息看，在对表“t_xxx_xxxxx”进行更新操作时，没找到相应的记录。

目前所有mysql主从采用4并发、半同步方式进行数据复制，以保证主从数据复制的效率与数据一致性。由本次具体出错信息看，当时正有4个线程在并发进行数据同步：

• 线程1：操作“5830d371-600d-11e8-bd61-fa163ef6f4ff:240662”事务

• 线程2：操作“5830d371-600d-11e8-bd61-fa163ef6f4ff:240659”事务

• 线程3：操作“5830d371-600d-11e8-bd61-fa163ef6f4ff:240660”事务

• 线程4：操作“5830d371-600d-11e8-bd61-fa163ef6f4ff:240661”事务

Mysql数据复制是在进行“5830d371-600d-11e8-bd61-fa163ef6f4ff:240662”事务操作时出现了“更新数据时，无法找到相应记录”错误。

1、分析binlog

分析“5830d371-600d-11e8-bd61-fa163ef6f4ff:240662”事务所在binlog：

该事务是个更新”t_xxx_xxxxx”的操作，修改记录”call_swftno=2018052713390100901288006”

其它三个事务为：

• 5830d371-600d-11e8-bd61-fa163ef6f4ff:240659

该事务为表“t_xxx_xxxxx”的insertinto on语句，共插入50条记录，其中包括记录“call_swftno=2018052713390100901288006”记录的插入

• 5830d371-600d-11e8-bd61-fa163ef6f4ff:240660

该事务为表“t_xxx_xxxxx”的insertinto on语句，共插入50条记录

• 5830d371-600d-11e8-bd61-fa163ef6f4ff:240661

该事务为表“t_xxx_xxxxxinfo”的更新操作

查看4个事务在主库上的提交次序

从“last_committed”值可以看出，事务“240659、240660、240661”并发运行，并同时提交，事务“240662”稍后提交。即在主库上，事务“240659、240660、240661”同时执行，事务“240662”随后执行。

2、备库事务运行

从应用逻辑出发，事务“240659”与“240662”是有执行次序的，不能同时执行。但基于mysql主从并发复制机制，并从备库复制出错信息看出，事务“240659、240660、240661、240662”在备库上是并发执行的，最终导致事务“240662”在执行时，由于事务“240659”还没执行完而找不到记录“call_swftno=2018052713390100901288006”的错误。

3、备库记录查询

在备库上查询“240662”事务更改所对应的记录，发现对应记录“call_swftno=2018052713390100901288006”存在，说明了事务“240659”在事务“240662”执行出错后，成功执行完成。

重启mysql主从复制线程，主从复制恢复正常，继续进行数据同步。

主库上短时间内有执行次序的相关操作，在从库上被基于并发主从复制的机制变更成了并发操作，导致了有依赖操作的事务出现“找不相关记录”错误。

所有机房内mysql主从复制配置都一致，但IDC机房内的数据是由前台业务系统产生的，具有一定的时间间隔，没产生这种现象，而淮安机房内的数据是由双中心同步软件同步产生的，短时间内产生大量有操作依赖的事务，便产生了上述错误现象。

Mysql参数“slave_preserve_commit_order“可以控制Slave上的binlog提交顺序和Master上的binlog的提交顺序一样，保证GTID的顺序。该参数只能用于开启了logicalclock并且启用了binlog的复制。即对于多线程复制，该参数用来保障事务在slave上执行的顺序与relaylog中的顺序严格一致。