答案：mysql主从复制故障恢复需先检查SHOW SLAVE STATUS，根据Slave_IO_Running和Slave_SQL_Running状态及Last_Error定位问题；SQL线程错误可跳过事务或手动修复数据；IO线程错误需排查网络、权限和binlog配置；数据不一致严重时应重建从库并用mysqldump或pt工具校验同步；关键在于精准判断错误类型并采取对应措施。
MySQL主从复制出现故障后，恢复的关键在于快速定位问题原因，并根据具体情况采取对应的修复措施。常见的故障包括网络中断、主库或从库宕机、数据不一致、GTID或binlog错误等。以下是几种常见场景下的恢复方法。
检查复制状态并定位问题
从库执行SHOW SLAVE STATUSG，重点关注以下字段：
- 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工具检测并修复差异。
基本上就这些。关键是要根据错误日志判断类型，选择跳过、修复或重建策略。定期监控复制状态，能有效减少故障影响。