首先确认复制错误类型并定位源头，通过SHOW SLAVE STATUS\G检查Slave_IO_Running、Slave_SQL_Running、Last_Error和Seconds_Behind_Master状态；根据错误类型判断是否为网络问题、GTID/位置不一致、主键冲突或表结构差异；针对不同情况采取跳过错误、使用pt-slave-restart工具、修复表结构或重新搭建从库等措施恢复复制；建议避免从库写入、定期校验数据一致性、启用GTID模式并监控延迟与日志以预防错误。
MySQL复制错误会影响主从数据一致性，及时排查和修复是关键。核心思路是确认错误类型、定位问题源头，并采取对应措施恢复复制。以下是常见排查步骤和方法。
查看复制状态
登录从库执行以下命令，观察复制线程状态：
SHOW SLAVE STATUS\G
重点关注以下字段：
Python v2.4 中文手册 chm
下载
Python v2.4版chm格式的中文手册，内容丰富全面，不但是一本手册，你完全可以把她作为一本Python的入门教程，教你如何使用Python解释器、流程控制、数据结构、模板、输入和输出、错误和异常、类和标准库详解等方面的知识技巧。同时后附的手册可以方便你的查询。
- Slave_IO_Running：是否正常拉取主库binlog
- Slave_SQL_Running：是否正常执行中继日志
- Last_Error 或 Last_SQL_Error：最近的错误信息
- Seconds_Behind_Master：延迟时间，为NULL表示有错误
分析常见错误类型
根据错误信息判断问题类别：
- 网络连接失败：检查主库IP、端口、防火墙、用户权限（REPLICATION SLAVE）
- GTID或文件位置不一致：主从binlog位置偏移，可能因手动修改数据或跳过事务导致
- 主键冲突或记录不存在：SQL线程执行INSERT时主键重复，或DELETE找不到行
- 表结构不一致：主库有字段，从库无此列，导致写入失败
处理复制中断的方法
根据实际情况选择恢复方式：
- 临时跳过错误：执行 SET GLOBAL sql_slave_skip_counter = 1; 再启动复制（仅限非关键冲突）
- 使用 pt-slave-restart 工具自动重启从库并跳过多条错误
- 重新搭建复制：备份主库数据，导出时带上正确的GTID或binlog位置，重建从库
- 修复表结构：确保主从表结构一致，可使用 pt-table-checksum 和 pt-table-sync
预防建议
减少复制错误的发生概率：
- 避免在从库写数据（除非配置双主）
- 定期校验主从数据一致性
- 启用GTID模式，简化故障恢复流程
- 监控复制延迟和错误日志，设置告警
