MySQL主从复制出错时，常见的表现包括从库延迟、SQL线程停止、错误日志报错等。排查这类问题需要系统性地查看状态、分析日志、定位异常点。以下是实用的排查步骤和技巧。
检查复制线程状态
登录从库执行SHOW SLAVE STATUS\G，重点关注以下字段：
Slave_IO_Running：是否正常拉取主库binlog Slave_SQL_Running：是否正常执行中继日志 Last_Error 和 Last_SQL_Error：最近的错误信息 Seconds_Behind_Master：当前延迟秒数（为NULL表示复制中断）如果任一线程为No，说明复制已中断，需结合错误信息进一步分析。
查看错误日志定位具体问题
MySQL错误日志通常位于/var/log/mysql/error.log或通过SHOW VARIABLES LIKE 'log_error';查看路径。常见错误包括：
主键冲突、记录不存在：多因数据不一致导致 表不存在：可能主库建表后未同步到从库 GTID相关错误：如Cannot execute the transaction with the given GTIDs网络连接失败：主库宕机或防火墙阻断
根据日志中的SQL语句和错误码，判断是数据问题、结构问题还是配置问题。
处理常见复制错误的方法
根据错误类型采取不同策略：
临时跳过错误：使用SET GLOBAL sql_slave_skip_counter = 1;跳过一条错误事务（仅适用于非关键错误） 修复数据一致性：通过pt-table-checksum和pt-table-sync工具校验并修复主从数据差异 重新初始化从库：备份主库数据，重新导入从库，重置复制位点 GTID模式下重置复制：清除旧GTID信息，使用RESET MASTER;和SET GTID_PURGED重新配置操作前务必确认错误是否可忽略，避免造成数据丢失或逻辑错误。
预防复制错误的建议
减少复制故障的关键在于规范运维：
避免在从库写入数据（除非双主架构且有控制机制） 主库DDL变更前，确认从库兼容性 启用read_only=ON防止误写从库 定期监控复制延迟和状态（可用Zabbix、Prometheus等工具） 开启log_slave_updates便于级联复制审计基本上就这些。只要掌握
SHOW SLAVE STATUS和错误日志分析，大多数复制问题都能快速定位。关键是反应及时，避免小问题演变成数据不一致的大故障。
