MySQL从库异常重启后必须重置位点，因relay-log.info未刷盘或relay log截断导致Relay_Master_Log_File和Exec_Master_Log_Pos失效，直接START SLAVE会卡住；仅当正常关闭、sync_relay_log=1、relay_log_recovery=ON且主库binlog未清理时才可能自动续同步。
MySQL从库重启后不一定需要重新定位位点，但SHOW SLAVE STATUS里显示的Relay_Master_Log_File和Exec_Master_Log_Pos可能已失效——这不是“必须重设”，而是因为重启过程破坏了中继日志（relay log）与主库 binlog 的连续性映射关系。
从库重启会丢弃未刷盘的 relay log 元信息
MySQL 从库把主库 binlog 拉过来后，先写入 relay log 文件，再由 SQL 线程执行。这个过程依赖两个关键元数据：
-
relay-log.info（或 mysql.slave_relay_log_info 表）：记录当前已执行到主库哪个Master_Log_File和Master_Log_Pos - 实际的 relay log 文件内容：包含已拉取但尚未执行的事件
如果从库是异常重启（如 kill -9、断电），relay-log.info 可能没及时刷盘，或 relay log 文件被截断。此时重启后，SQL 线程会按旧位置尝试继续执行，但对应位置的事件可能根本不存在，导致 Slave_SQL_Running: No 和 Last_SQL_Error 报错，比如 Could not parse relay log event entry 或 log_pos XXX beyond end of file。
为什么不能直接用 SHOW SLAVE STATUS 里的 Position 启动？
重启后 SHOW SLAVE STATUS 显示的 Relay_Master_Log_File 和 Exec_Master_Log_Pos 是上次正常停止时记录的值，但有三个现实问题：
- 主库 binlog 可能已被
expire_logs_days清理，该 position 对应的文件已不存在 - 从库 relay log 文件本身损坏或不完整（尤其在 sync_relay_log=0 时）
- GTID 模式下，
Exec_Master_Log_Pos不参与定位，但Retrieved_Gtid_Set和Executed_Gtid_Set若未持久化也会出错
所以直接 START SLAVE 很可能卡住，而不是自动“续上”。你看到的 “Yes” 状态只是线程启动了，不代表它真能执行下去。
什么情况下可以跳过重定位？
只有满足全部以下条件，重启后才大概率无需干预：
- 从库是正常关闭（
mysqladmin shutdown或 systemd stop） - 启用了
sync_relay_log = 1和relay_log_recovery = ON（MySQL 5.6+ 默认开启） - 主库 binlog 未被 purge，且 relay log 文件完整可读
即便如此，仍建议重启后立刻执行 SHOW SLAVE STATUS\G 确认 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes，且 Seconds_Behind_Master 开始下降。只要其中任一字段为 No，就必须介入——不是“要不要重定位”，而是“已经断了，得修”。
真正容易被忽略的是：relay log 恢复逻辑只在启动时触发一次，且依赖 relay_log_recovery 配置；如果这个开关关了，或者 MySQL 版本低于 5.6，重启几乎必然丢失同步上下文。
