mysql的slave报1236的话如何自动修复呢

Posted 2023-04-13

在网上看了很多版本都没有得到解决方案，有知道的回复一下。图片的错误目前不知道是什么原因导致mysql5.7主从互备中断的，用了gtid方法。slave_max_allowed_packet=1*1024*1024*1024max_allowed_packet = 512M

参考技术A 由于主服务器异外重启, 导致从报错, 错误如下:
show slave status错误:

mysql> show slave status\G
Master_Log_File: mysql-bin.000288
Read_Master_Log_Pos: 627806304
Relay_Log_File: mysql-relay-bin.000990
Relay_Log_Pos: 627806457
Relay_Master_Log_File: mysql-bin.000288

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

 

【问题二】

有一个集群（MySQL5.7.23）切换后复制slave报1236，其实是不小心在slave上执行了事务导致

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.

【产生原因】

定时任务在执行flush slow logs前未加set sql_log_bin=0;导致在slave上执行时，slave上的GTID增长，当binlog日志被purge后，发生MHA切换后就会报出上面的错误。

 

【修复步骤】

下面描述正确的处理步骤：

1、切换后如果出现replication报错，第一时间先关闭master的binlog备份

2、修复导致slave事务增长的job脚本set sql_log_bin=0; flush slow logs

3、slave上stop slave;

4、master上show global variables like \'%gtid%\';记录gtid_purged，gtid_executed值

 

5、slave上reset master;

6、slave上set global gtid_purged=\'3d9ade83-7cea-11e5-bc12-d89d6725f98c:1-863017556,

8fad86b1-8980-11e8-873d-40a8f024a124:1-24531;

这里需要注意，设置的值应该是上面截图红色框两段组合的值，这样才能保证再次切换后复制正常

7、slave上start slave;

对于这次的场景，按上次步骤恢复后会丢失8fad86b1-8980-11e8-873d-40a8f024a124:1-24531这段事务，但这段事务实际上是flush slow logs事务，并不影响业务数据，因此理论上数据会一致

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

复制相关的文章

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