mysql主从同步失败怎么办_复制错误修复

来源：这里教程网时间：2026-02-28 20:37:29 作者：

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 必须在主库执行，并确认已成功同步