主从复制断开后Seconds_Behind_Master为NULL表明SQL线程已停止，需先检查Slave_IO_Running、Slave_SQL_Running及Last_IO_Error/Last_SQL_Error定位故障点；GTID模式下跳过事务须用SET GTID_NEXT+空事务，严禁sql_slave_skip_counter；重设复制起点需关闭MASTER_AUTO_POSITION并指定MASTER_GTID_SET，以主库现存gtid_executed为准。
主从复制断开后，SHOW SLAVE STATUS 显示 Seconds_Behind_Master: NULL 怎么办
这通常意味着 SQL 线程已停止，IO 线程可能也挂了，不是延迟高，而是彻底卡死。先别急着跳错误，得先确认停在哪、为什么停。
执行 SHOW SLAVE STATUS\G，重点看三处：Slave_IO_Running、Slave_SQL_Running 和 Last_IO_Error / Last_SQL_Error。如果 SQL_Running 是 No，且 Last_SQL_Error 提到“Duplicate entry”或“no such table”，大概率是数据不一致触发了中断；如果是 “error connecting to master”，那问题在 IO 层（网络、权限、防火墙）。
- 先用
START SLAVE IO_THREAD尝试恢复 IO（只拉日志，不执行），再观察Seconds_Behind_Master是否开始变化 - 若 IO 能跑但 SQL 还卡住，说明中继日志里已有冲突语句，此时跳错才有意义
- 切勿在没查清错误类型前直接
SET GLOBAL sql_slave_skip_counter = 1——GTID 模式下这个命令会报错
GTID 模式下怎么安全跳过一个事务错误
GTID 不允许用 sql_slave_skip_counter，必须靠 SET GTID_NEXT 注入空事务来“占位”，让从库认为该 GTID 已执行过。
步骤严格分三步，缺一不可：
- 停复制：
STOP SLAVE - 设单次 GTID：
SET GTID_NEXT = 'xxx-xxx-xxx:nnn'（值来自Last_SQL_Error中的 GTID，如3e11fa47-71ca-11e1-9e33-c80aa9429562:23） - 执行空事务：
BEGIN; COMMIT;，再重置 GTID_NEXT：SET GTID_NEXT = 'AUTOMATIC' - 重启：
START SLAVE
注意：如果 Last_SQL_Error 里 GTID 是多个（如 ...:23-25），不能只跳一个，得按范围逐个注入，否则后续 GTID 序列会断。跳完立刻查 Executed_Gtid_Set 确认是否包含刚注入的 GTID。
CHANGE MASTER TO ... GTID_SET 什么时候必须用，怎么写才不丢数据
当从库缺失大量中继日志（比如磁盘损坏、手动清了 relay-log），或主库已切换、旧 binlog 被 purge，就无法靠跳错续传，必须重新定位 GTID 起点。
关键不是“找最新 GTID”，而是“找主库上还存在的最老 GTID”——即主库 SELECT @@global.gtid_executed 的结果，或者用 SHOW MASTER STATUS 查当前 Executed_Gtid_Set。
- 在从库执行前，先确保主库没开启
gtid_purged自动清理（检查SELECT @@gtid_purged是否为空或合理） -
CHANGE MASTER TO MASTER_HOST='x', ..., MASTER_AUTO_POSITION=0—— 必须关掉自动位置，否则GTID_SET参数无效 -
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=123, MASTER_GTID_SET='xxx:1-100'——MASTER_LOG_FILE/POS只是占位，实际以MASTER_GTID_SET为准 - 执行后
START SLAVE，观察Retrieved_Gtid_Set是否开始增长
跳错后 SHOW SLAVE STATUS 里 Retrieved_Gtid_Set 不变，是不是失败了
不是失败，是正常现象。Retrieved_Gtid_Set 只反映“从主库拉到本地中继日志里的 GTID”，而跳错或 GTID_SET 重设只影响 SQL 线程执行起点，不触发重新拉日志。
真正要看的是：Executed_Gtid_Set 是否在增长、Seconds_Behind_Master 是否回落、Slave_SQL_Running 是否为 Yes。
- 如果
Executed_Gtid_Set卡住不动，说明 SQL 线程又遇到新错误，得再查Last_SQL_Error - 如果
Retrieved_Gtid_Set和Executed_Gtid_Set相等，但Seconds_Behind_Master是 0，说明已追平 - GTID 模式下永远不要依赖
Relay_Log_File和Relay_Log_Pos判断进度——它们在 GTID 启用后只是冗余字段
GTID 的一致性保障很硬，但操作门槛也高：跳错必须精确到 GTID，重定位必须确保主库未 purge 对应日志，这两点漏掉任何一个，后续就会反复断、反复错。
