为什么MySQL从库在重启后需要重新定位位点信息

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 STATUSG 确认 Slave_IO_Running 和 Slave_SQL_Running 都为 Yes，且 Seconds_Behind_Master 开始下降。只要其中任一字段为 No，就必须介入——不是“要不要重定位”，而是“已经断了，得修”。

真正容易被忽略的是：relay log 恢复逻辑只在启动时触发一次，且依赖 relay_log_recovery 配置；如果这个开关关了，或者 MySQL 版本低于 5.6，重启几乎必然丢失同步上下文。