MySQL复制中断后恢复的关键是定位问题原因，然后根据具体情况采取对应措施。常见原因包括主从数据不一致、网络故障、GTID配置问题、日志丢失等。以下是几种典型场景的恢复方法。
检查复制状态
首先通过以下命令查看从库的复制状态：
SHOW SLAVE STATUS\G重点关注以下字段：
Slave_IO_Running：IO线程是否运行 Slave_SQL_Running：SQL线程是否运行 Last_Error：最近的错误信息 Seconds_Behind_Master：延迟时间 Last_IO_Error / Last_SQL_Error：具体错误描述常见中断原因及恢复方法
根据错误类型选择合适的恢复方式：
1. 主库日志被清理（Relay log not found）如果错误提示“Could not find first log file name in binary log index file”，说明主库的binlog已被删除，从库无法继续拉取。
重新配置复制起点，使用当前主库最新的binlog位置重建从库 或使用备份+binlog增量恢复从库数据 推荐使用mysqldump或
xtrabackup重新搭建从库 2. 数据冲突导致SQL线程停止
如出现主键冲突、记录不存在等错误，可临时跳过错误事务：
STOP SLAVE;SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
注意：仅适用于非关键性冲突，跳过需谨慎，避免数据进一步不一致。
3. GTID模式下复制中断在GTID复制中，若出现“Unknown database”或“Duplicate entry”错误，可通过注入空事务跳过：
STOP SLAVE;SET GTID_NEXT='指定报错中的GTID值';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;
确保GTID值与错误日志中的一致。
4. 网络或主库宕机恢复后网络恢复后，通常从库会自动重连并继续复制。若未恢复，执行：
STOP SLAVE;START SLAVE;
观察是否恢复正常。
重建从库（终极方案）
当数据差异过大或多次出错时，建议重新初始化从库：
在主库执行mysqldump --master-data=2 --single-transaction导出数据 将备份恢复到从库 根据导出文件中的CHANGE MASTER TO语句重新配置复制 启动复制：
START SLAVE;
基本上就这些。关键是先看错误日志，判断能否跳过或必须重建。小问题可以手动修复，大问题不如重做从库来得稳定。
