1 、故障描述

某次，由于客户需要进行机房搬迁，需要手动对一套MySQL MHA 进行计划性切换，但切换后之后发现主从复制同步异常，提示报错如下：

                Last_IO_Errno: 1236

                Last_IO_Error: 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. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period. The GTID sets and the missing purged transactions are too long to print in this message. For more information, please see the master's error log or the manual for GTID_SUBTRACT.'

2 、根因分析

通常来讲，计划性切换都比较可控，出现失败的概率和风险相对较低。那导致本次异常的原因究竟是什么，点位不一致、 GTID 号混乱，还是其他原因？需要进一步分析。

1 、正常情况下，从库是不会有 binlog 写入的，此时我们需要确认一下，新主库（原从库）的 binlog 文件保留策略为 7 天

mysql> show variables like 'expire_logs_days';

+------------------+-------+

| Variable_name    | Value |

+------------------+-------+

| expire_logs_days | 7    |

+------------------+-------+

2 、检查新主库（原从库）是否开启 log_slave_updates ， off 代表作为从库是，不会将主库复制的数据在从库的 binlog 再进行一次写入，就不会有新的 binlog 产生

mysql> show variables like 'log_slave_updates';

+-------------------+-------+

| Variable_name     | Value |

+-------------------+-------+

| log_slave_updates | OFF   |

+-------------------+-------+

3 、查看新主库（原从库）现有 binlog 文件数，发现 binlog 文件名为 mysql-bin.000006,1-5 的 binlog 已经不存在了

mysql> show binary logs;

+------------------+-----------+

| Log_name         | File_size |

+------------------+-----------+

| mysql-bin.000006 |       2736504973|

+------------------+-----------+

1 row in set (0.00 sec)

4 、新主库（原从库）解析现有 binlog ，发现 d0e1531e-320b-11ef-9b5b-0e4925de1a7e:1-4613 为上一个 mysql-bin.000005 的事务号，但 mysql-bin.000005 已删除

mysqlbinlog -vv  mysql-bin.000006 | more

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#240625  9:45:41 server id 624133740  end_log_pos 123 CRC32 0x0deacd86         Start: binlog v 4, server v 5

.7.37-log created 240625  9:45:41

# Warning: this binlog is either in use or was not closed properly.

BINLOG '

RSF6Zg9shjMldwAAAHsAAAABAAQANS43LjM3LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA

AYbN6g0=

'/*!*/;

# at 123

#240625  9:45:41 server id 624133740  end_log_pos 234 CRC32 0xb78efa7f         Previous-GTIDs

# d0e1531e-320b-11ef-9b5b-0e4925de1a7e:1-4613

# at 234

#240625 10:08:14 server id 624133740  end_log_pos 299 CRC32 0xeef5878e         GTID     last_committed=0    sequence_number=1      rbr_only=yes

/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;

SET @@SESSION.GTID_NEXT= 'd0e1531e-320b-11ef-9b5b-0e4925de1a7e:4614'/*!*/;

# at 299

5 、从库上 purge 掉丢失的事务号即可

stop slave;

reset slave;

reset master;

set @@GLOBAL.GTID_PURGED ='d0e1531e-320b-11ef-9b5b-0e4925de1a7e:1-4613,d8e05853-31ed-11ef-956d-c2d49fafca8c:1-957627,f50a3e49-31eb-11ef-9306-0e4925de1a7e:1-166163';

change master to master_host='192.168.239.52',master_port=33071,master_user='repl',master_password='Repl#123',master_auto_position=1;

start slave;

6 、复制正常 show slave status;

3 、原理分析

原则上主从复制异常，提示主库 binlog 文件丢失，就代表了数据丢失，需要重新构建主从复制。

本次问题的出现，是发生在手动主从切换过程，切换之前的主从复制是正常的，从库 binlog 过期失效，不会导致切换主从后数据丢失。只会导致主从切换后，复制异常。

因为主库记录的 Executed_Gtid_Set ，包含了从库的 gtid ，且从库的 gtid 是不会发生变化的，通过 show master status 可获取。如果从库 binlog 发生了人为的切换，就会导致主库记录的从库 gtid 对应 binlog 过期丢失。

4 、总结建议

MySQL MHA ，从库要做以下策略：

1 、从库 read_only 、 super_read_only 设置为 ON

2 、从库上禁止 reset master 、 flush logs 等影响 binlog 的操作

3 、从库上 log_slave_updates 参数要设置为 OFF