17370845950

SHOW SLAVE STATUS\G 是定位MySQL主从复制中断的唯一可靠入口，需检查IO/SQL线程状态、Seconds_Behind_Master及Last_IO/SQL_Error等关键字段。

主从复制中断后如何快速定位原因

MySQL 主从复制断开时，SHOW SLAVE STATUS\G 是唯一可靠入口。重点关注 Slave_IO_Running 和 Slave_SQL_Running 是否为 Yes，以及 Seconds_Behind_Master 是否持续增长或为 NULL。

常见中断现象与对应线索：

• IO线程停止：通常指向网络、权限或主库 binlog 不存在（如被误删、过期清理）；检查 Last_IO_Error
• SQL线程停止：多因从库执行 SQL 失败，比如主键冲突、表结构不一致、DDL 被跳过但后续 DML 依赖该结构；看 Last_SQL_Error
• Seconds_Behind_Master = NULL 且两个线程都为 Yes：说明 IO 已拉取日志但 SQL 线程卡在某个事件，需结合 Relay_Log_Pos 和 Exec_Master_Log_Pos 对比判断是否积压

跳过单条错误继续同步的实操边界

仅当确认错误是**可安全忽略的数据层冲突**（例如主库重复插入同一主键，且业务允许从库以主库为准覆盖），才使用跳过机制。不可用于结构变更失败、字符集不兼容、GTID 模式下位置错乱等场景。

具体操作分两种模式：

• 传统 binlog 位置模式：

  STOP SLAVE;
  SET GLOBAL sql_slave_skip_counter = 1;
  START SLAVE;

• GTID 模式（推荐）：

  STOP SLAVE;
  SET GTID_NEXT='ac6a95c2-1234-11ef-8001-00155d012345:12345';
  BEGIN; COMMIT;
  SET GTID_NEXT='AUTOMATIC';
  START SLAVE;

  其中 ac6a95c2-...:12345 需替换为 SHOW SLAVE STATUS\G 中 Retrieved_Gtid_Set 里缺失的那个事务号

注意：sql_slave_skip_counter 在 GTID 模式下被禁用，强行设置会报错 ERROR 1776 (HY000): Cannot use sql_slave_skip_counter when @@GLOBAL.GTID_MODE = ON。

全量重做同步前必须验证的三件事

当数据不一致严重、跳过不可行或无法定位源头时，重做同步是稳妥选择，但代价高，务必先确认：

• 主库 my.cnf 中已启用 log-bin 且 server-id 唯一；否则从库无法获取新日志
• 主库当前 SHOW MASTER STATUS 的 File 和 Position 值未被 purge（可通过 SHOW BINARY LOGS 查看最老 binlog 文件名，对比是否仍存在）
• 从库上无正在运行的写入应用，且已停掉所有可能修改数据的定时任务或脚本；否则 mysqldump 导出期间数据会变动，导致 dump 不一致

典型重做流程（GTID 模式）：

mysqldump --all-databases --single-transaction --triggers --routines --events --host=master_ip --user=replica_user --password=xxx > full_dump.sql
# 在从库停复制、清空数据、导入
mysql -e "STOP SLAVE; RESET SLAVE ALL;"
mysql < full_dump.sql
mysql -e "SET GLOBAL gtid_purged='ac6a95c2-1234-11ef-8001-00155d012345:1-12345'; START SLAVE;"

其中 gtid_purged 值必须与主库 SELECT @@global.gtid_executed; 输出完全一致，否则启动失败报 error 1236。

从库延迟突增却显示“正常运行”的隐藏陷阱

Seconds_Behind_Master = 0 并不等于实时同步完成。它只反映 SQL 线程已执行完 relay log 中最后一个事件，但若主库正批量写入大事务（如 ALTER TABLE、百万级 INSERT ... SELECT），从库可能仍在回放该事务内部语句，此时监控看到的延迟是滞后的。

真正有效的观测方式：

• 查 SHOW PROCESSLIST 中 Slave_SQL 线程状态，长期停留在 executing 或 updating，说明正在处理大事务
• 对比主库 SHOW MASTER STATUS 的 Position 与从库 Exec_Master_Log_Pos 差值（非 GTID 模式下），差值持续增大即真实延迟
• 开启 performance_schema 表 replication_applier_status_by_coordinator，观察 APPLYING_EVENT 的耗时分布

这类延迟无法靠重启复制解决，只能优化主库事务粒度、升级从库硬件或启用并行复制（slave_parallel_workers > 0 且 slave_parallel_type = LOGICAL_CLOCK）。