MySQL主从复制出现故障后，恢复的关键在于快速定位问题原因，并根据具体情况采取对应的修复措施。常见的故障包括网络中断、主库或从库宕机、数据不一致、GTID或binlog错误等。以下是几种常见场景下的恢复方法。
检查复制状态并定位问题
从库执行SHOW SLAVE STATUS\G，重点关注以下字段：
Slave_IO_Running：是否正常拉取主库binlog Slave_SQL_Running：是否正常执行中继日志 Last_Error：最近的错误信息，是排查的关键 Seconds_Behind_Master：延迟时间通过错误信息判断是IO线程还是SQL线程出错，再决定后续操作。
处理SQL线程错误（如数据冲突）
如果SQL线程报错，比如主键冲突或记录不存在，说明从库执行事件时出现问题。常见解决方式有：
跳过错误事务：执行SET GLOBAL sql_slave_skip_counter = 1，然后START SLAVE。适用于偶发性错误，但需谨慎使用，避免数据进一步不一致。 使用GTID跳过事务：
如果启用了GTID，在从库执行SELECT GTID_NEXT获取当前事务，然后设置SET GTID_NEXT='xxxx'，执行空事务后重置GTID_NEXT。 手动修复数据：
根据错误提示，手动在从库补全缺失数据或删除冲突记录，再启动复制。
处理IO线程错误（无法连接主库）
IO线程失败通常与网络或权限有关：
确认主库网络可达，防火墙未阻止3306端口 检查主库是否仍允许复制用户登录：使用SHOW GRANTS FOR 'repl'@'xxx'确认权限 检查主库binlog文件是否存在，position是否有效
若主库重启或清空过binlog，可能需要重新配置CHANGE MASTER TO 必要时重新配置主从：
执行STOP SLAVE，RESET SLAVE ALL，再用正确的MASTER_HOST、MASTER_LOG_FILE、MASTER_LOG_POS重新配置
数据一致性校验与重建从库
若发现数据严重不一致，建议重建从库：
在主库使用mysqldump --single-transaction --master-data=2导出数据 将dump文件导入从库 从导出文件中提取CHANGE MASTER语句，正确配置从库指向主库的binlog位置 启动复制：START SLAVE也可使用pt-table-checksum和pt-table-sync工具检测并修复差异。
基本上就这些。关键是要根据错误日志判断类型，选择跳过、修复或重建策略。定期监控复制状态，能有效减少故障影响。
