MySQL 5.7基于GTID复制的常见问题和修复步骤(一)

【问题一】

复制slave报错1236，是较为常见的一种报错

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

需要注意有多种场景都会导致1236错误，error code都是1236，但后面的错误描述会不同

【产生原因】

这个错误发生在slave的IO线程从master拉取日志时，发现gtid_next在master的binlog.index中第一个文件中不存在。

通常出现在新搭slave , 忘记关闭主库的binlog备份。

或者slave由于某些原因停止了一段时间，而这段时间master上的binlog被purge掉了，导致从库获取不到对应的binlog文件。

【保证数据一致性的修复步骤】

1、到对应的master上查询当前gtid_purged值，show global variables like '%gtid%'; 并记录下来

Variable_name: gtid_purged

        Value: 698da8d5-a743-11e7-a2ab-384c4fb16868:1-245780670,

82634550-10fb-11e6-81fc-384c4fb16868:1-1714684630,

cc85f79f-10ff-11e6-8202-384c4fb16888:1-6127989,

fd1bea9b-5194-11e7-bad5-384c4fb16888:1-1579848406

2、在报错的slave上执行show global variables like '%gtid%';并将gtid_executed记录下来

Variable_name: gtid_executed

        Value: 698da8d5-a743-11e7-a2ab-384c4fb16868:1-242405257,

82634550-10fb-11e6-81fc-384c4fb16868:1-1714684630,

cc85f79f-10ff-11e6-8202-384c4fb16888:1-6127989,

fd1bea9b-5194-11e7-bad5-384c4fb16888:1-1579848406

3、到binlog备份目录下找被pugre掉的包含 698da8d5-a743-11e7-a2ab-384c4fb16868:1-242405257的GTID的binlog文件，并从备份目录拷贝到当前slave服务器上的目录

4、在当前slave上执行还原脚本，直到还原到大于等于gtid_purged的位置，多还原没有问题，因为已经执行过的GTID，在salve的SQL线程重做时会跳过

mysqlbinlog -vvv /data/binlog/bin.file |mysql -u -p

如果出现报错，可以尝试导出SQL文件source执行

mysqlbinlog -vvv /data/binlog/bin.file > 1059.sql

source 1059.sql

 5、start slave;

【不考虑数据一致性的修复步骤】

在某些特殊场景下，比如日志文件缺失，需要快速恢复，或是测试环境可以丢失一部分数据

1、master上执行show global variables like '%gtid_executed';并记录

2、slave上一次依次执行，这种方法会丢失掉上次salve报错时 Executed_Gtid_Set的位置86c67cfe-8b18-11e8-9e4c-246e965710f8:1-16到新位置86c67cfe-8b18-11e8-9e4c-246e965710f8:1-23之间的，16-23集合的事务

stop slave;

reset master;

set global gtid_purged='86c67cfe-8b18-11e8-9e4c-246e965710f8:1-23';

start slave;

上述方法修复后，都建议用pt-table-checksum工具，检验主从数据的一致性。

原文出处： https://www.cnblogs.com/wangdong/p/9951626.html