答案：MySQL主从复制出错常见表现为延迟、SQL线程停止、错误日志报错；排查需依次检查复制线程状态（SHOW SLAVE STATUS）、分析错误日志定位问题，根据错误类型采取跳过事务、修复数据、重置复制等措施，并通过规范运维预防故障。
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和错误日志分析，大多数复制问题都能快速定位。关键是反应及时，避免小问题演变成数据不一致的大故障。
