MySQL 5.7 mysqldump的Bug导致复制异常

标签：停止   nlog   启动mysql   eset   change   主机   date   flush   规范   

DB版本：5.7.17

问题描述：mysqldump逻辑搭备库都相信大家都使用的非常普遍，大致做法如下：

1、在源库上mysqldump  --single-transaction --master-data=2   -A  ... >XXX.sql

2、在目标备库上stop slave;reset master; reset slave all; source XXX.sql

3、如果导入了用户信息需要flush privileges生效

4、change master  to .. master_auto_position=1;

5、start slave完事

查看复制状态一切正常...

看起来很规范，整个过程很顺畅,没毛病！

问题来了：mysql或者主机需要维护重启。正常停止完了启动mysql,start slave发现复制出错了！！！why？

https://bugs.mysql.com/bug.php?id=82848  BUG在此

说是mysql的bug其实如果了解mysql 5.7针对GTID复制的优化以后，是可以避免这个坑的：

1、5.7不需要备库开启log-slave-updates选项，也就无需读写binglog来计算复现的事务信息了

2、作为改进，mysql库新增了一张表gtid_executed表用来记录执行过的事务信息

3、该表并不是实时更新的，只有binlog switch或者mysql shutdown的时候更新

基于这3点：由于mysqldump全库导入了,mysql.gtid_executed也导入到mysql库了.由于该表没有及时更新（由于gtid不同，在新库已经无法正常更新）.这样重启后读取mysql.gtid_executed作为gtid_executed的信息，并以此状态向主库复制。就会拿到已经执行或的binlog继续应用，重复执行导致复制报错。

how to do：

mysqldump时增加--ignore-table =mysql.gtid_executed或者增加-F 参数触发mysql.gtid_executed数据更新

MySQL 5.7 mysqldump的Bug导致复制异常

标签：停止   nlog   启动mysql   eset   change   主机   date   flush   规范   

原文地址：http://www.cnblogs.com/xingye001/p/7762754.html