MySQL主从复制中断后，恢复的关键是确保主库和从库的数据一致性，并重新建立复制链路。以下是常见场景下的恢复步骤。
检查复制状态
登录从库，执行：
SHOW SLAVE STATUS\G重点关注以下字段：
Slave_IO_Running：是否正常拉取主库binlog Slave_SQL_Running：是否正常执行中继日志 Last_Error：最近的错误信息 Seconds_Behind_Master：延迟时间常见问题与恢复方法
根据错误类型选择对应的处理方式：
1. 主库binlog被删除或丢失如果错误提示“Could not find first log file name”，说明从库请求的binlog在主库已不存在。
解决方法：
重新搭建从库：对主库做一次完整备份（如mysqldump或xtrabackup） 在从库导入数据并重新配置CHANGE MASTER TO指向新的binlog位置 2. SQL线程错误（如主键冲突、表不存在）常见于手动修改了从库数据或结构不一致。
临时跳过错误的方法：
STOP SLAVE;SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
注意：此操作跳过一条事件，仅适用于非关键性错误，生产环境慎用。
3. GTID模式下复制失败GTID环境中，需确保从库的gtid_purged包含主库已执行的事务。
恢复步骤：
确认主库的GTID集合：SHOW MASTER STATUS; 从库停止复制：STOP SLAVE; 重置GTID信息（谨慎操作）： RESET MASTER;SET GLOBAL gtid_purged = '主库的gtid_executed值';
CHANGE MASTER TO MASTER_HOST='...', MASTER_AUTO_POSITION=1;
START SLAVE;
重建主从复制（彻底恢复）
当数据差异较大时，建议重新初始化从库：
主库导出数据：mysqldump --master-data=2 --single-transaction db_name > backup.sql 将备份传到从库并导入：mysql 根据backup.sql中的CHANGE MASTER TO语句配置复制 启动复制：START SLAVE;预防措施
避免频繁中断复制：
主库不要随意清理老的binlog文件（通过expire_logs_days控制） 避免在从库执行写操作 定期监控复制延迟和状态 使用pt-heartbeat等工具检测复制健康度基本上就这些。关键是根据错误日志判断原因，选择安全的恢复方式，优先保证数据一致性。不复杂但容易忽略细节。
