MySQL复制环境如果中断或出现异常，可以通过以下步骤恢复。核心是确保主从数据一致性，并重新建立复制关系。
检查复制状态
登录到从库，执行：
SHOW SLAVE STATUS\G关注以下字段：
Slave_IO_Running：是否正常拉取主库binlog Slave_SQL_Running：是否正常执行中继日志 Last_Error：最近的错误信息 Seconds_Behind_Master：延迟时间根据错误类型决定恢复方式。
常见问题与恢复方法
1. 主库binlog被清理导致IO线程报错
错误提示通常包含“Could not find first log file”或“Got fatal error 1236”。
解决方案：
重新做一次完整备份并导入从库 使用mysqldump导出主库数据： mysqldump -h master_host -u user -p --master-data=2 --single-transaction db_name > backup.sql 导入到从库： mysql -u root -p 查看文件中的CHANGE MASTER TO语句里的binlog位置，配置从库： STOP SLAVE; CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000xxx', MASTER_LOG_POS=xxxx; START SLAVE;2. SQL线程错误（如主键冲突、表不存在）
若错误可忽略，临时跳过错误：
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;注意：sql_slave_skip_counter=1只跳过一个事件，适用于非关键冲突。生产环境慎用。
更安全的方式是手动修复数据：
查错误涉及的表和数据 在从库补全缺失数据或删除冲突行 重启复制使用GTID模式恢复（推荐）
若启用了GTID（gtid_mode=ON），恢复更简单。
从主库查看当前GTID集：
SHOW MASTER STATUS;在从库执行：
STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO MASTER_HOST='master_ip', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_AUTO_POSITION = 1; START SLAVE;MySQL会自动同步未应用的事务，无需手动指定binlog位置。
预防措施
主库设置expire_logs_days合理值，避免过早清理binlog 定期监控复制延迟和状态 从库开启read_only防止误写 使用MMM、MHA或Orchestrator等工具实现高可用基本上就这些。关键是判断错误类型，选择重建复制还是跳过错误。GTID模式下恢复更可靠，建议新环境启用。
