首先确认复制错误类型和位置，通过SHOW SLAVE STATUS\G查看Slave_IO_Running和Slave_SQL_Running状态及Last_Error信息；若为网络问题需检查连接配置，GTID不一致时谨慎调整gtid_purged，主键冲突可设sql_slave_skip_counter跳过，表结构不一致用pt-table-checksum修复；结合error log与relay log定位细节；日常应同步时间、启用read_only、定期校验数据并监控延迟，确保复制稳定。
MySQL复制出错时，首先要确认错误类型和位置。通过查看从库的复制状态信息，定位问题源头，再针对性处理。以下是常用的排查步骤和方法。
检查复制状态
登录从库执行以下命令，查看复制线程运行情况：
SHOW SLAVE STATUS\G重点关注以下两个字段：
- Slave_IO_Running：是否正常拉取主库binlog
- Slave_SQL_Running：是否正常执行中继日志
如果任一为“No”，说明复制中断。同时查看Last_Error或Last_IO_Error字段，获取具体错误信息。
常见错误类型及处理
根据错误信息分类处理：
- 网络连接失败：检查主库IP、端口、防火墙、用户权限是否正确。确保主库允许从库连接。
- GTID不一致：出现“gtid_consistency”或“set gtid_next”相关错误时，可通过设置gtid_purged跳过事务，但需谨慎操作。
- 数据冲突（如主键重复）：SQL线程报错1062，可临时跳过错误：
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;
建议先备份数据，避免数据不一致扩大。 - 表结构不一致：主从表结构差异导致INSERT/UPDATE失败。使用pt-table-checksum工具检测并修复。
查看日志辅助诊断
MySQL错误日志通常记录更详细的异常信息：
- 查看error log路径：在配置文件中找log-error参数，或执行SHOW VARIABLES LIKE 'log_error';
- 结合relay log分析具体执行语句：mysqlbinlog relay-bin.xxxxxx
预防与维护建议
减少复制错误发生频率：
- 主从服务器时间同步（使用NTP）
- 定期校验数据一致性
- 避免在从库写入数据
- 启用read_only=ON防止误操作
- 监控复制延迟（Seconds_Behind_Master）
基本上就这些。关键是要及时发现、准确判断、稳妥处理。复制问题不可忽视，长期不同步可能导致故障恢复失败。
