mysql 1756 报错 的原因

-------------------------------------------------------------------------------------------------正文---------------------------------------------------------------------------------------------------------------

转载 https://yq.aliyun.com/articles/285353

库上报错   ER_MTS_INCONSISTENT_DATA;  看了大致 跟master info相关 查看日志 也跟下面的图一样，但是 start salve

复制起不来， 发现日志是在恢复 mts 并行复制，尝试  reset salve  ， start slave 复制起来恢复，回家查看资料 查看到这位同学

博客，发现跟我相似，发现这位同学写的很好！ 直接就拷贝





与此同时，不管是start slave还是change master都无法完成，会在error-log中不断的刷新类似的错误信息；

由于业务主库A降级是在磁盘空间写满以后，所以可以确认备库B上的业务操作不可能会在A上面执行，两个库之间不会有一致性的问题；
于是选择了reset slave all+change master的方式，重新恢复了同步；

故障报告写完以后，再详细研究一下这种现象的原因：
找到一个bug记录：发生于MySQL-5.6
http://bugs.mysql.com/bug.php?id=77496
并且在5.7.12中也发现过：
https://bugs.mysql.com/bug.php?id=80102

在comment中，提到了relay_log_recovery=ON和slave-parallel-type=LOGICAL_CLOCK时会出现这个问题；
恰好正在出问题的库也是这种设置；

发生错误的原因：
基于在5.6的Group Commit特性，5.7中实现了Mutil-Thread-Slave的特性，多个线程会同时复现relay-log中， 同一组的事务；
因此multi-threaded replication slave在运行过程中，如果意外的停止了，由于无法确认事务的一致性，在开启了relay_log_recovery的情况下，会出现如截图中的信息；

官方推荐的恢复步骤：
1.设置relay_log_recovery=0；
2.启动slave的时候，带上特殊命令：START SLAVE UNTIL SQL_AFTER_MTS_GAPS；
3.设置relay_log_recovery=1；
非常重要的一点：relay_log_recovery不是一个动态的参数，需要重启数据库实例；

这个问题在5.7.13得到了修复，整个操作步骤会在重启的时候自动进行；重启的时候...重启的...重启...

虽然和bug文档以及官方描述的场景不同，不过上文中出现的情况应该是同一个原因造成的；
好在能够确认A库上的multi-threaded replication slave不可能出现事务不一致的情况，所以就简单粗暴的清除了slave的信息，然后重新进行了同步；