主从复制中断后如何快速定位原因
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;<br>SET GLOBAL sql_slave_skip_counter = 1;<br>START SLAVE;GTID 模式（推荐）：
STOP SLAVE;<br>SET GTID_NEXT='ac6a95c2-1234-11ef-8001-00155d012345:12345';<br>BEGIN; COMMIT;<br>SET GTID_NEXT='AUTOMATIC';<br>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<br># 在从库停复制、清空数据、导入<br>mysql -e "STOP SLAVE; RESET SLAVE ALL;"<br>mysql < full_dump.sql<br>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）。
