并行复制ERROR 1755/1756故障处理

在官方版本的MySQL5.6中，并行复制已经可以使用，基于database，局限性比较大。5.7以后，实现了真正意义上的“并行”，基于组提交（logical clock）。本文主要分享一些ERROR 1755/1756故障的处理方法及原因，部分是官方已认定的BUG。

ERROR 1755

导致这个错误的原因很多，通过此处只列出几个特殊场景下的例子。

1） Reason：The master event is logically timestamped incorrectly

目前只在MySQL-5.6 ---> MySQL-5.7 这个结构中发现，MySQL-5.7中开启了基于逻辑时钟的MTS，master的event没有记录并行复制的相关信息。这种跨大版本的结构可能同样导致ERROR 1756（见后面）

原因：

Slave的复制分发对象被为，但5.6是仅支持粒度的并行复制。

那么为什么5.7使用基于的就会出现这个问题呢？

因为在5.7的中，新增了和

前者表示事务提交时，上次提交的事务编号，若事务具有相同的，则表明这些事务在同一个组内，可以并行进行apply

这两者的出现，也是5.7新增基于进行并行复制的基础。

无论在开启GTID还是关闭GTID的情况下，都会有对应信息的产生。

在5.7中，MYSQL_BIN_LOG定义了两个Logical_clock的变量：

max_committed_transaction：记录上次提交事务的logical_clock，即last_committed。

transaction_counter：记录当前组提交中各事务的logical_clock，即sequence_number。

而5.6所产生的binlog是没有这些记录的，作为slave的5.7自然无法基于logical_clock进行并行复制。

解决办法：

① 关闭MTS

② 修改为5.6的方式

2） Reason: the event is a part of a group that is unsupported in the parallel execution mode.3） Reason: possible malformed group of events from an old master.

2）3）可以统一到一起，主要发生在老版本的MySQL-5.6的MTS结构中。

按报错，通过字面可理解为部分event group无法被SLAVE所正常应用。

bug #71495：

https://bugs.mysql.com/bug.php?id=71495

bug #72537：

https://bugs.mysql.com/bug.php?id=72537

ERROR 1755可大致可以理解为，master上产生的events是无法被slave通过并行复制的方式正常应用的。

如果真的遇到了，可以看看当时执行的events是否有奇怪的语句。MySQL-5.6的并行复制比较鸡肋，关闭MTS功能总是最稳健的解决方案，此外，在5.6中，使用传统单线程复制可能还会更快。要用MTS，上5.7+吧。

ERROR 1756

这个错误场景可能更多，在我遇到的1756里，错误信息报出来也会千奇百怪。

文档上也比较简单：

1） 最为常见的一种ERROR 1756

这是一个知名BUG：（在MySQL5.6和MySQL5.7高版本被修复）

bug #77239：

https://bugs.mysql.com/bug.php?id=77239

原因是由于InnoDB死锁而无法执行事务，或者因为事务的执行时间超过了InnoDB的innodb_lock_wait_timeout

有趣的是，这个error会在错误日志中被打印出三次，也被人认为是个bug：

bug #77237：

https://bugs.mysql.com/bug.php?id=77237

bug #77237 在MySQL-5.6.30和MySQL-5.7.12修复：

当然，除了是个bug #77239，也可能是字面意思，即DDL或者非事务引擎导致，如果发生此错误，也可以看一下当时主库在干什么。

bug #77239的稳定复现方法：

上述测试以下环境测试下来均可：

解决方案：

① 重新开启sql_thread：

② 关闭MTS（真万能）：

google了一下，这个报错（The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).）

老叶也遇到过，但是他定位的原因和我理解的不太一致：

有兴趣可看一下：

FAQ系列 | 从MySQL 5.6到5.7复制错误解决

http://imysql.cn/?p=4118

2） @@slave_transaction_retries在MTS中无效

这个要结合1）来看。

首先，这个参数的作用是，遇到1）中的1756情况，则会在出错之前自动重试次。

而在一些版本里，这个值在MTS中没用的，从而导致1756（正确设置这个参数本该可以避免）。

部分版本里，开启MTS会有提示：

在5.7的文档上也写的很明白：

简单来说，就是5.7.5之前，在MTS结构中，被视为0。

围观请看：

bug #68465：

https://bugs.mysql.com/bug.php?id=68465

MySQL官方这个就让人很懵了，既然当时还不支持，手册上又没有，又有多少人遇到这个问题会去懂去源码描述。（源码里的确写了不支持）

当然在Yoshinori Matsunobu巨佬反馈后的几个月后，官方更新了手册：

3）和XA事务有关的ERROR 1756

不太确定是否为bug，是否可复现。

提交“bug”的同学是一个中国人，有兴趣可以去看一下：

这个被MySQL官方技术支持大佬Umesh Shastry先生认定为Duplicate，即和1）中的问题重复。

bug #80180：

https://bugs.mysql.com/bug.php?id=80180

写作3）仅为多一个在遇到ERROR 1756时的参考case。

ERROR 1755/1756 的总结：

避免跨版本的并行复制。（如果非要，关闭MTS）

升级到5.6.x的更高版本，避免使用老版本5.6的并行复制。

升级到5.7.x的更高版本，避免使用老版本5.7。

-- 可能感兴趣的文章

-- the end --