问题背景:
在搭建完成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方式, 存在比较大的风险;最好还是避免这类问题的发生;