问题背景:
在搭建完成GTID复制环境以后, 从库show slave status\G输出可以看到Slave_IO_Running和Slave_SQL_Running状态是YES

主库show master status输出

从库show master status输出

看起来主从结构并没有什么问题，但当把从库关闭再重启启动的时候，show master status输出却变成：

1937661e-4a69-11e7-a82d-00155d016710:1-6不见了？事实上, 这些GTID事务是主库mysqldump全备文件中的，也就是说, 主库mysqldump出1-6的事务导入从库做的GTID复制，把主从关系建立起来，复制也没问题，而从库mysqld实例重启以后，这些全备的事务丢失了？如果这样就执行start slave肯定出问题！！！

经过分析，这个问题与mysql.gtid_executed有关！

在主库执行select * from mysql.gtid_executed; 返回空, 而从库

解决办法就是把interval_start的最小的值由7改为1
set sql_log_bin=0;
update mysql.gtid_executed set interval_start=1 where source_uuid='1937661e-4a69-11e7-a82d-00155d016710' and interval_start=7;
set sql_log_bin=1;
重启mysqld，可以看到show master status输出正常,执行start slave;主从关系恢复正常;

那怎么避免这个问题的发生呢？在主库备份之前，确认purged掉的gtid已经写入mysql.gtid_executed中,有时可能没有及时写入这个表,可以kill -HUP $(pgrep msyqld)触发写这个表，有时可能执行一次kill不行的，可以执行多几次。

最后一定要注意, 遇到这种情况，可以忽略GTID事务的，可以通过跳过GTID事务的方式修复解决；而如果通过reset master和gtid_purged方式, 存在比较大的风险;最好还是避免这类问题的发生;