SHOW SLAVE STATUS中Seconds_Behind_Master为NULL且IO/SQL线程为No，表明复制已中断而非延迟；需据Last_IO_Error或Last_SQL_Error类型采取对应措施：网络问题查连通性，SQL错误需确认数据一致性，binlog缺失则需重设坐标，relay log损坏须手动删除后RESET SLAVE，GTID模式下跳过事务须严格校验gtid_purged与gtid_executed关系。
SHOW SLAVE STATUS 显示 Seconds_Behind_Master 为 NULL 或 IO/SQL 线程为 No
这说明复制链路已断，不是延迟高，而是彻底停了。常见现象是 Slave_IO_Running 和/或 Slave_SQL_Running 显示 No，Seconds_Behind_Master 为 NULL，同时 Last_IO_Error 或 Last_SQL_Error 里有具体报错。
先别急着重设坐标，先看错误类型再决定动作：
- 如果是网络类（如
error connecting to master），检查主库可达性、账号权限、防火墙 - 如果是 SQL 报错（如
Duplicate entry、Unknown column），说明从库数据已偏离主库，不能直接跳过，得先确认是否允许数据不一致 - 如果是 binlog 文件被主库清理（
Could not find first log file name in binary log index file或log event entry exceeded max_allowed_packet），这才是需要重新定位坐标的情况
主库上执行 SHOW MASTER LOGS 找不到从库当前请求的 binlog 文件
这是最典型的“坐标失效”场景：从库还在找 mysql-bin.000123，但主库 SHOW MASTER LOGS 里最大只有 mysql-bin.000120——文件已被 expire_logs_days 或手动 PURGE BINARY LOGS 清掉。
此时必须人工介入定位新起点，不能靠 START SLAVE 自动恢复：
- 用
SHOW MASTER STATUS查主库当前最新 binlog 名和 position（比如File: mysql-bin.000120，Position: 198765） - 如果从库
Relay_Master_Log_File比这个还旧（如mysql-bin.000119），说明缺失部分不可逆，只能全量重同步或接受丢数据 - 如果只是 position 落后（如从库卡在
mysql-bin.000120的1000，主库已到198765），可安全执行CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000120', MASTER_LOG_POS=198765
CHANGE MASTER TO 执行后 START SLAVE 报错 ERROR 1236
ERROR 1236 是坐标类错误的集中地，典型信息如：Could not parse relay log event entry.、binlog truncated in the middle、log event entry exceeded max_allowed_packet。根本原因是 relay log 或主库 binlog 损坏，或从库本地 relay log 文件不完整。
这时不能硬调坐标，得清掉损坏的 relay log：
- 先
STOP SLAVE - 删掉从库
relay-log文件（路径看Relay_Log_File值，通常在 datadir 下，文件名类似hostname-relay-bin.000004） - 执行
RESET SLAVE（注意：它会清空master.info和relay-log.info，但不会删 relay log 文件，所以要先手动删） - 再
CHANGE MASTER TO ...设置新坐标，START SLAVE
漏掉手动删 relay log 是最常见的翻车点——RESET SLAVE 不等于“重置一切”，它只清元数据，不碰磁盘文件。
从库启用 GTID 后同步中断，想跳过事务但不确定怎么写 GTID_SET
启用了 gtid_mode=ON 的从库，不能再用 MASTER_LOG_FILE/POS，必须用 GTID_SUBSET 和 GTID_PURGED。出错时 Last_SQL_Error 会明确提示缺失哪个 GTID，比如 aaaa-bbbb-cccc-dddd:12345。
跳过单个事务的操作链很脆，稍错就导致 GTID 集不一致：
- 先
STOP SLAVE - 查当前
SELECT @@global.gtid_executed;，记下完整集合（如aaaa-bbbb-cccc-dddd:1-12344） - 把要跳过的 GTID 接上去，变成
aaaa-bbbb-cccc-dddd:1-12344,aaaa-bbbb-cccc-dddd:12345 - 执行
SET GLOBAL gtid_purged = 'aaaa-bbbb-cccc-dddd:1-12344,aaaa-bbbb-cccc-dddd:12345'; - 再
START SLAVE
关键点：赋值给 gtid_purged 的字符串必须是严格子集或等价于 gtid_executed，否则 MySQL 启动会拒绝。线上环境建议先在测试实例验证 GTID 字符串格式。
