主从复制中断时Seconds_Behind_Master为NULL且IO/SQL线程为No，表明复制已停止而非延迟；需先查Last_IO_Error/Last_SQL_Error定位原因，再根据Relay_Master_Log_File和Exec_Master_Log_Pos等安全重设位置。
主从复制中断后，SHOW SLAVE STATUS 显示 Seconds_Behind_Master: NULL 且 Slave_IO_Running 或 Slave_SQL_Running 为 No
这说明复制链路已断开，不是延迟高，而是彻底停了。常见原因是网络闪断、主库重启未保留 binlog 位置、从库磁盘满导致 relay log 写失败，或人为误操作跳过了错误但没补数据。
别急着 CHANGE MASTER TO 重配——先看错在哪：
-
SHOW SLAVE STATUS\G重点看Last_IO_Error和Last_SQL_Error字段，比如error connecting to master是连不上主库，Could not execute Write_rows_v1 event则是 SQL 线程在执行某条 DML 时崩了 - 若
IO_Running=No且错误是authentication failed，大概率是主库改了复制用户密码，或从库CHANGE MASTER里用的还是旧密码 - 若
SQL_Running=No，错误里带duplicate entry或no such table，说明从库数据已和主库不一致，强行START SLAVE会卡死
用 CHANGE MASTER TO 重新指定位置时，MASTER_LOG_FILE 和 MASTER_LOG_POS 怎么取才不丢数据
不能凭感觉填，也不能直接抄主库当前 SHOW MASTER STATUS 的值——那是最新位置，从库很可能还没消费到那里。正确做法是找从库最后成功执行的位置：
- 如果
SQL_Running=No但IO_Running=Yes，看Relay_Master_Log_File和Exec_Master_Log_Pos，这两个就是从库 SQL 线程刚执行完的那条语句在主库 binlog 中的位置 - 如果 IO 和 SQL 都挂了，且 relay log 还在（默认在
datadir下以relay-bin.000xxx开头），可用mysqlbinlog --base64-output=decode-rows -v解析最后一个 relay log 文件末尾，找到最后一条COMMIT对应的end_log_pos - 千万别用
MASTER_AUTO_POSITION=1后再手动指定位置，二者互斥；启用了 GTID 就必须用SET GLOBAL gtid_slave_pos = 'xxx'方式重设
执行 CHANGE MASTER TO 后 START SLAVE 立刻又报错
说明问题没根治，只是换了个地方崩。典型情况是主从表结构不一致、从库有残留的临时表、或者主库开了 binlog_format=STATEMENT 但执行了无法被安全复制的函数（如 NOW()、UUID()）。
- 检查主从两边同名表的
CREATE TABLE输出是否完全一致，尤其注意ENGINE、COLLATION、默认值、自增起始值 - 从库上运行
SELECT * FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'xxx' AND TABLE_NAME = 'yyy'\G，确认没有tmp_开头或#sql-开头的残留表 - 若主库 binlog_format 是
STATEMENT，避免在业务中写INSERT INTO t VALUES (NOW())这类语句；改成MIXED或ROW更稳妥
修复后验证复制是否真正追平，而不是“看起来在跑”
Seconds_Behind_Master: 0 不等于已追平——它只反映 SQL 线程当前执行位置和 IO 线程拉到的最新位置之间的差值。如果 IO 线程根本没动，这个值也会是 0。
- 连续执行两次
SHOW SLAVE STATUS\G，间隔 10 秒，对比Read_Master_Log_Pos和Exec_Master_Log_Pos是否都在增长，且差值稳定缩小 - 在主库执行
INSERT INTO test_sync VALUES (UNIX_TIMESTAMP());，立刻去从库查这条记录是否存在、时间戳是否一致（误差应在 1 秒内） - 如果主库开启了
log_slave_updates，还能在从库上执行SHOW BINLOG EVENTS IN 'mysql-bin.000xxx' LIMIT 10，确认 relay log 里的事件确实被落盘成了本地 binlog
最麻烦的情况是主库 binlog 被 purge 了，而从库还没读完——这时 CHANGE MASTER TO 指定的位置已不存在，只能重搭从库。别省那点磁盘空间，expire_logs_days 设成 7 天起步。
