MySQL 5.7并发复制隐式bug实例分析

前言

我们MySQL线上环境大部分使用的是5.7.18的版本，这个版本已修复了很多bug，但针对主从复制的bug还是有很多的，尤其是一些组复制、并行复制的bug尤为突出，在5.7.19版本有做相应改善和修复。所以建议5.7.19之前的版本还是不要使用mgr和并发复制的功能，如使用建议升级至5.7.19（含）以后的版本。

我这里遇到的问题主要是莫名其妙的数据同步出现问题，无法执行stop slave，数据不一致等现象，经过查看发现是版本bug所致，所以对已上线的从库关闭并发复制，对未上线的系统实行版本升级。此风险非常非常高，各位务必重视。

具体5.7.19修复的复制bug如下：

参考手册：https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-19.html

References: See also: Bug #84107.

Replication: In the case of delayed initialization of the Group Replication plugin, deployed in single-primary mode, secondaries were able to get writes through an asynchronous replication channel, which is not allowed in normal initialization of the Group Replication plugin. (Bug #26314756)

Replication: With GTIDs generated for incident log events, MySQL error code 1590 (ER_SLAVE_INCIDENT) could not be skipped using the --slave-skip-errors=1590 startup option on a replication slave. (Bug #26266758)

Replication: A USE statement that followed a SET GTID_NEXT statement sometimes had no effect. (Bug #26128931)

Replication: Groups can now contain members running different server versions to enable you to do online upgrades of a replication group. The rules for combining members in a group with different versions are:

If you have a group with 8.0 members, you cannot add a 5.7 member

If you have a group with 5.7 members you can add a 8.0 member, but it remains in read-only mode. Writing to this member is dangerous while the group contains multiple server versions and should be avoided.

In a single-primary group, if the current primary leaves the group and a new primary must be elected, the primary is first chosen from the lower version members. If no lower version member is found, the primary is chosen from newer version members. (Bug #25876807)

Replication: When binlog_checksum=NONE was set on a MySQL server after startup, and then Group Replication was started, if an error occurred, the server remained in RECOVERING state and could not be shut down. (Bug #25793366, Bug #85667)

Replication: In a Group Replication setup where circular asynchronous replication was implemented between members of different replication groups, view change log events were repeatedly replicated between the groups with new generated GTIDs each time. The fix ensures that view change log events are ignored outside the named replication group where they occur, and never generate new GTIDs. (Bug #25674926)

References: See also: Bug #26049695, Bug #25928854, Bug #25721175.

Replication: When first starting the MySQL server following an installation from RPM, passwword validation plugin is activated by default (true only for RPM installations). If binary logging was already enabled at this time, the activation was logged, even though plugin activations should not be recorded in the binary log. (Bug #25672750)