首先检查SHOW SLAVE STATUS\G中的Last_Error、Last_IO_Error和Last_SQL_Error等字段定位问题，根据错误类型选择恢复方式：1. 临时错误可跳过单个事务；2. GTID模式下通过SET GTID_NEXT跳过多事务；3. 数据严重不一致时重新初始化从库；4. 网络或权限问题需修复连接与授权。
MySQL复制失败后，恢复的关键在于定位问题原因并采取对应措施。常见原因包括主从数据不一致、网络中断、GTID配置错误、日志丢失等。以下是常见的恢复方法和操作步骤。
检查复制错误信息
复制失败时，先通过SHOW SLAVE STATUS\G查看详细状态，重点关注以下字段：
- Last_Error：显示最近的错误信息
- Last_IO_Error：IO线程错误，通常与网络或权限有关
- Last_SQL_Error：SQL线程错误，常因数据冲突或语句执行失败引起
- Slave_IO_Running 和 Slave_SQL_Running：确认哪个线程停止
根据错误提示判断是网络问题、权限不足、日志缺失，还是数据不一致。
常见恢复方法
根据错误类型选择合适的恢复方式：
1. 跳过单个错误事务
适用于临时性错误（如主键冲突、记录已存在）：
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
注意：此方法仅跳过一条错误事件，不推荐频繁使用，可能造成数据不一致。
2. 基于GTID的复制恢复
若使用GTID模式，可在从库跳过多事务：
STOP SLAVE; SET GTID_NEXT='caa9715c-12a9-11eb-8000-acde48001123:12345'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;
或在配置文件中设置gtid_executed跳过特定事务。
3. 重新初始化从库（推荐用于严重不一致）
- 在主库执行mysqldump导出数据
- 锁表并记录主库binlog位置：FLUSH TABLES WITH READ LOCK; + SHOW MASTER STATUS;
- 导出数据：mysqldump --all-databases --master-data=2 --single-transaction > backup.sql
- 解锁：UNLOCK TABLES;
- 将备份导入从库，重启复制
4. 修复网络或权限问题
确保从库能连接主库：
- 检查主库是否允许远程连接（bind-address）
- 确认复制用户存在且有REPLICATION SLAVE权限
- 测试网络连通性和端口访问（3306）
预防复制失败的建议
为减少复制中断概率：
- 定期监控复制延迟（Seconds_Behind_Master）
- 启用relay_log_recovery=1防止中继日志损坏
- 使用半同步复制提高数据安全性
- 避免在从库写入数据
- 定期校验主从数据一致性（如pt-table-checksum）
基本上就这些。关键是及时发现错误，合理选择恢复方式，必要时重建从库保证数据一致。
