MySQL从库重启后为何需重新定位位点信息

MySQL从库一旦重启，位点信息就丢失，这确实是个让人头疼的问题。严格来说，倒不是说“必须重设”，但SHOW SLAVE STATUS里那两个关键字段——Relay_Master_Log_File和Exec_Master_Log_Pos——在重启后很可能变得不可靠。根本原因在于，重启操作本身破坏了中继日志（relay log）与主库binlog之间的连续性映射关系。

元数据未刷盘，重启后一切归零

要理解这个问题，首先得搞懂从库的工作机制。简单来说，从库把主库的binlog拉取过来，先存成relay log文件，然后SQL线程再去执行。这里面有两个关键角色：

• relay-log.info（或者mysql.slave_relay_log_info表）：像一个记账本，记录着SQL线程已经执行到主库的哪个binlog文件和哪个具体位置。
• relay log文件本身：这里面存放的是已经拉取下来但尚未执行的事件。

问题就出在，如果从库是异常重启的（比如kill -9、断电），这个“记账本”可能还没来得及存盘，或者relay log文件本身被截断了。重启后，SQL线程会拿着旧账本上的位置去执行，却发下那个位置的事件早已不存在。于是，你就会看到Slave_SQL_Running: No，紧接着报错，比如Could not parse relay log event entry或者log_pos XXX beyond end of file。这才是最让人头疼的情况。

为什么不能直接拿SHOW SLAVE STATUS里的位置启动？

你可能会想，重启后看到的SHOW SLAVE STATUS里不是还显示着上次正常停止时的位置吗？理论上没错，但现实往往很骨感，主要有三个坑：

• 主库的binlog可能已经被expire_logs_days参数清理掉了，那个位置对应的文件已经不存在了。
• 从库的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，那么重启几乎必然导致同步上下文丢失。所以，提前做好配置，比事后手忙脚乱要靠谱得多。