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数据更新