MySQL主从同步失败需先定位错误类型再修复，不可盲目重启；通过SHOW SLAVE STATUS查看IO/SQL线程状态、错误号及延迟等关键字段；常见错误包括主键冲突（1062）、表不存在（1146）、记录缺失（1032），对应跳过或手工修复；GTID模式下应使用SET GTID_NEXT跳过事务；预防措施包括开启log_slave_updates、设置read_only、定期校验数据一致性及监控延迟。
MySQL主从同步失败时，核心是定位错误类型、跳过或修复异常事件，再恢复复制。不能盲目重启复制，否则可能跳过关键数据或导致数据不一致。
查看复制状态和错误详情
登录从库执行：
SHOW SLAVE STATUS\G
重点关注以下字段：
- Slave_IO_Running 和 Slave_SQL_Running：是否为 Yes；任一为 No 表示复制中断
- Last_IO_Errno/Last_IO_Error：IO线程报错（如网络、权限、主库binlog缺失）
- Last_SQL_Errno/Last_SQL_Error：SQL线程报错（如主键冲突、表不存在、语句在从库执行失败）
- Seconds_Behind_Master：延迟秒数，为 NULL 通常表示复制已停止
- Relay_Master_Log_File + Exec_Master_Log_Pos：当前已执行到主库哪个 binlog 文件和位置
常见错误类型及对应修复方式
根据 Last_SQL_Error 内容判断，主流错误分三类：
-
主键/唯一键冲突（1062）：主库插入了从库已存在的记录（比如从库误写、主从数据被人工修改）。可跳过该事件：
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE; - 表不存在（1146）：从库缺少某张表（如建表语句未同步、被误删）。应先确认主库是否存在该表，再手工在从库创建相同结构的表，然后启动复制
- 找不到记录（1032）：从库执行 UPDATE/DELETE 时找不到对应行（数据不一致）。需比对主从该行数据，补全从库缺失数据，或用 sql_slave_skip_counter 跳过（仅限确认无业务影响时）
安全跳过错误的替代方案（推荐）
直接设 sql_slave_skip_counter 风险高，尤其在 GTID 模式下不可用。更稳妥的做法：
- 若启用 GTID（gtid_mode=ON），用：
STOP SLAVE;
SET GTID_NEXT='xxx-xxx-xxx:nnn';（填报错事务的 GTID）
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE; - 临时关闭从库写保护（如 read_only=ON），执行修复语句后立即恢复
- 使用 pt-slave-restart（Percona Toolkit 工具）自动监控并按策略跳过指定错误
预防同步失败的关键措施
修复只是补救，长期稳定靠规范运维：
- 主从都开启 log_slave_updates（便于级联复制和故障切换）
- 从库设置 read_only=ON，禁止应用直连写入
- 定期校验主从数据一致性（如 pt-table-checksum）
- 监控 Seconds_Behind_Master 波动，设置告警阈值（如持续 > 300 秒）
- 避免在从库执行 DDL；DDL 必须在主库执行，并确认已成功同步
