MySQL双中心复制引起主从复制异常处理分享丨本际云推荐

MySQL双中心复制引起主从复制异常处理分享

MySQL主从复制异常处理分享

我是本际云服务器推荐网的小编小本本，今天要和大家分享一下MySQL主从复制异常处理的经验。

MySQL双中心复制引起主从复制异常处理分享

故障描述

在双中心建设期间，部分MySQL备库出现了复制出错现象，所有出错信息一致，具体出错原因为：更新数据时无法找到相应记录。所有MySQL主从采用4并发、半同步方式进行数据复制。在并发进行数据同步时，出现了更新数据时无法找到相应记录的错误。

故障分析

从具体出错信息看，在对表“t_xxx_xxxxx”进行更新操作时，没找到相应的记录。以此为出发点，分析binlog可以看出事务运行的并发次序，从而找到问题。

首先，分析事务所在binlog。该事务是更新“t_xxx_xxxxx”表的操作，修改记录“call_swftno=2018052713390100901288006”。在备库上，同样的4个线程在并发执行，事务“240659、240660、240661”并发进行提交，稍后才执行事务“240662”。由于事务的执行顺序不同，最终导致事务“240662”执行时找不到相关记录，从而出现了错误。

在备库上查询“240662”事务更改所对应的记录，可以发现对应记录“call_swftno=2018052713390100901288006”是存在的，说明事务“240659”在事务“240662”执行出错后，成功执行完成。故障处理需要重启MySQL主从复制线程才能恢复正常，继续进行数据同步。

故障总结

在这个故障中，重点是主库上短时间内有执行次序的相关操作，在从库上被基于并发主从复制的机制变更成了并发操作，导致有依赖操作的事务出现了“找不到相关记录”错误。由于不同IDC机房内数据产生间隔时间不同，导致产生差异。参数“slave_preserve_commit_order”可以控制Slave上的binlog提交顺序和Master上的binlog的提交顺序一样，保证GTID的顺序。该参数只能用于开启了logicalclock并且启用了binlog的复制。即对于多线程复制，该参数用来保障事务在Slave上执行的顺序与relaylog中的顺序严格一致。

以上就是本次MySQL主从复制异常处理分享，希望能对大家有所帮助。

原创文章，作者：小编小本本，如若转载，请注明出处：https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/5863.html