MySQL主从同步依赖主库的binlog日志和从库的relay log实现数据同步，当同步中断后如果主库的binlog已经被自动清理或者手动删除，从库就无法获取缺失的同步日志，常规的重启同步操作会直接报错。此时需要根据业务情况选择合适的恢复方案，避免数据丢失或者主从不一致。
binlog被删后同步失败的原因
MySQL主从同步的核心流程是主库将写操作记录到binlog，从库的IO线程拉取主库binlog保存到本地relay log，SQL线程重放relay log完成数据同步。当同步中断后，如果从库需要的binlog文件已经被主库删除，从库IO线程拉取日志时会返回文件不存在的错误，同步进程就会卡住无法继续。
主库删除binlog通常有两种情况，一种是开启了expire_logs_days参数，binlog超过保留天数自动清理，另一种是手动执行了PURGE BINARY LOGS命令删除了指定binlog。不管哪种情况，只要从库还没同步的binlog被删除，就无法通过常规方式恢复同步。
方案一：从备份恢复从库
如果业务有定期的全量备份，并且备份时间点在同步中断之前，可以通过备份恢复从库数据，再重新建立同步关系。这种方案适合数据量不大，或者备份可用的场景。
操作步骤
- 停止从库的同步进程，避免恢复过程中产生冲突
- 使用最新的全量备份恢复从库的数据，恢复后从库的数据状态和备份时间点一致
- 查看备份文件对应的主库binlog位置，通常全量备份的文件中会记录备份时的binlog文件名和偏移量
- 重新配置从库同步，指定备份对应的binlog位置开始同步
- 启动从库同步进程，检查同步状态是否正常
操作示例
首先停止从库同步：
-- 从库执行，停止同步 STOP SLAVE;
假设全量备份是用mysqldump导出的，备份文件中会有如下记录：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=156;
恢复数据后，重新配置从库同步：
-- 从库执行，配置主库同步信息，替换为实际的主库IP、端口、账号密码和binlog位置 CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_PORT=3306, MASTER_USER='sync_user', MASTER_PASSWORD='sync_password', MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=156;
启动同步并检查状态：
-- 启动同步 START SLAVE; -- 查看同步状态，确保Slave_IO_Running和Slave_SQL_Running都是Yes SHOW SLAVE STATUSG
方案二：直接重建主从同步
如果没有可用的全量备份，或者数据量较小，可以直接重建主从同步关系。这种方案会将主库当前全量数据同步到从库，再开启同步，适合业务允许短时间主从数据不一致的场景。
操作步骤
- 主库执行全量数据导出，导出时加上
--master-data参数，会自动记录当前的binlog位置 - 将导出的数据文件传输到从库服务器
- 从库清空原有数据，导入主库导出的全量数据
- 根据导出文件中的binlog位置配置从库同步
- 启动从库同步，检查同步状态
操作示例
主库导出全量数据，--master-data=2会将binlog位置信息作为注释写入导出文件：
mysqldump -uroot -p --all-databases --master-data=2 > full_backup.sql
查看导出文件中的binlog位置信息：
grep "CHANGE MASTER TO" full_backup.sql
从库先停止同步，清空原有数据（如果是新从库可以跳过清空步骤），导入主库数据：
# 从库执行，导入数据 mysql -uroot -p < full_backup.sql
导入完成后，配置从库同步，替换为实际的binlog位置：
-- 从库执行 CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_PORT=3306, MASTER_USER='sync_user', MASTER_PASSWORD='sync_password', MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=345;
启动同步并检查状态：
START SLAVE; SHOW SLAVE STATUSG
注意事项
- 操作前建议先备份从库现有数据，避免操作失误导致数据丢失
- 重建同步过程中，主库的写操作会同步到从库，如果主库有持续写入，同步完成后从库数据会和主库完全一致
- 如果是生产环境，操作尽量在业务低峰期进行，避免影响业务正常使用
- 同步恢复后，建议定期检查主从同步状态，避免再次出现同步中断的问题
如果主从同步中断后binlog被删除，不要尝试手动修改从库的同步位置跳过缺失的binlog，这样会导致主从数据不一致，后续出现数据问题时更难排查。优先选择备份恢复或者重建同步的方案，保障数据的一致性。