必须主动干预，先通过SHOW SLAVE STATUS\G判断Slave_IO_Running或Slave_SQL_Running是否为No以确认中断，再据错误类型选择跳过、重设位点、同步gtid_purged或重建从库；自动重连仅是基础，关键在保障Relay Log与Binlog连续一致。
SHOW SLAVE STATUS\G 一查就清楚：只要 Slave_IO_Running 或 Slave_SQL_Running 是 No，说明主从链路已断，不能靠“重启服务”或“重跑 START SLAVE”自动恢复——必须根据中断原因重新建立关系。
主库 binlog 被清理导致 IO 线程失败
典型错误：Could not find first log file name in binary log index file 或 Client requested master to start replication from position > file size。这表示从库要拉的 binlog 文件在主库上已不存在。
- 不能跳过、不能重设
sql_slave_skip_counter，因为 IO 线程根本连不上起点 - 必须重新初始化从库：用
mysqldump --master-data=2 --single-transaction导出主库全量数据（注意保留CHANGE MASTER TO语句里的File和Position） - 导入后，在从库执行备份文件里生成的
CHANGE MASTER TO命令，再START SLAVE - 如果主库启用了 GTID，导出时加
--set-gtid-purged=ON，否则从库gtid_purged会为空，后续同步失败
SQL 线程报错但 IO 正常（如主键冲突、表结构不一致）
常见于人为在从库写了数据，或 DDL 没同步到位。此时 Slave_IO_Running: Yes，但 Slave_SQL_Running: No，Last_Error 明确提示冲突或找不到表。
- 先确认错误是否可跳过：
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;——仅适用于单条非业务关键语句（比如一条重复 INSERT） - 更安全的做法是：停复制 → 手动修复从库缺失/冲突对象（如删掉多余行、补建表）→
START SLAVE - 若错误涉及 DDL（如
ALTER TABLE失败），必须确保主从表结构完全一致后再启动 SQL 线程，否则会反复报错 - GTID 模式下禁用
sql_slave_skip_counter，要用SET GTID_NEXT='xxx'; BEGIN; COMMIT;注入空事务绕过，操作门槛高，建议优先修复源头
GTID 模式下 gtid_purged 不匹配
错误现象：Retrieved_Gtid_Set 有值，Executed_Gtid_Set 为空，Seconds_Behind_Master 为 NULL，START SLAVE 无反应。本质是从库不知道自己“该从哪开始同步”。
- 先在主库查：
SHOW MASTER STATUS;记下Executed_Gtid_Set - 从库执行：
STOP SLAVE; RESET MASTER;（⚠️清空本地所有 GTID 记录，慎用） - 然后：
SET GLOBAL gtid_purged = '主库的 Executed_Gtid_Set 值'; - 最后：
CHANGE MASTER TO MASTER_HOST='x', MASTER_USER='y', MASTER_PASSWORD='z', MASTER_AUTO_POSITION=1;→START SLAVE - 注意：
gtid_purged必须包含主库所有已提交事务的 GTID，漏一个就会卡住；若主库 binlog 已被删，只能走全量重建
双主或多节点拓扑中某条链路失效
比如 A→B→C 架构中 B 到 C 断了，但 A→B 还通。此时不能只修 B→C，还要检查 log_slave_updates 是否开启 —— 它决定 B 是否把自己的变更写进 binlog 给 C 拉。
- B 节点配置中必须有：
log_slave_updates=ON（MySQL 5.7+ 默认关闭，需显式启用） - 若之前没开，即使重启 B 的复制，C 也收不到 B 的更新，必须补开 + 重启 B 的 MySQL（或动态设置后
FLUSH LOGS） - 检查 B 的
SHOW MASTER STATUS中File是否在增长，不增长说明log_slave_updates未生效 - 多节点场景下，每个中间节点都要单独验证其 binlog 是否包含上游变更，不能只看最终从库状态
Seconds_Behind_Master 归零且持续稳定”。很多操作看似成功，但 Relay_Log_Pos 不动、Read_Master_Log_Pos 卡住，或者 GTID 集合不再增长，都意味着同步实际未生效。 
