我们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)
Replication: In a setup where single-primary Group Replication was combined with asynchronous replication, for example with S1 and S2 forming a group and with S2 and S3 functioning as master and slave, secondaries such as S2 were accepting transactions and these could then enter the group. The fix prevents secondaries creating an asynchronous replication channel when belonging to a single-primary group, and Group Replication cannot be started when asynchronous replication is running. (Bug #25574200, Bug #85047)
References: See also: Bug #86325, Bug #26078602.
Replication: In the event that a member failed to join a group the member was not stopping and continued to accept transactions. To avoid this set your members to have super_read_only=1 in the my.cfg file. Group Replication now checks for this setting upon successful start up and sets super_read_only=0. This ensures that members which do not successfully join a group cannot accept transactions. (Bug #25474736, Bug #84728)
Replication: If the binary log on a master server was rotated and a full disk condition occurred on the partition where the binary log file was being stored, the server could stop unexpectedly. The fix adds a check for the existence of the binary log when the dump thread switches to next binary log file. If the binary log is disabled, all binary logs up to the current active log are transmitted to slave and an error is returned to the receiver thread. (Bug #25076007)
Replication: Interleaved transactions could sometimes deadlock the slave applier when the transaction isolation level was set to REPEATABLE-READ. (Bug #25040331)
Replication: If a relay log index file named relay log files that did not exist, RESET SLAVE ALL sometimes did not fully clean up properly. (Bug #24901077)
Replication: The slave_skip_errors system variable did not permit error numbers larger than 3000. Thanks to Tsubasa Tanaka for the patch. (Bug #24748639, Bug #83184)