确认relay log被删后，应执行stop slave、reset slave all、change master to对齐主库位点，再start slave；relay_log_recovery=on仅在启动时生效且需repository为table才有效。
确认 relay log 确实被删了，别猜
看到 Slave_SQL_Running: No 且 Seconds_Behind_Master: NULL，先别急着重搭。关键看错误日志里有没有 Could not open log file 或 Failed to open the relay log 'xxx-relay-bin.000005' (errno 2)。再查 SHOW SLAVE STATUS\G 中的 Relay_Log_File 值，比如是 mysql-relay-bin.000123，然后去从库 datadir（通常是 /var/lib/mysql/）下执行：
ls -l mysql-relay-bin.000123如果文件不存在，再检查
relay-log.index 是否还记录着它——index 有但磁盘无，基本坐实被删。
STOP SLAVE 后必须用 RESET SLAVE ALL，不能只删文件
手动 rm -f mysql-relay-bin.* 是最危险操作：MySQL 不会自动重建 relay log，START SLAVE 时 SQL 线程仍会尝试读已删文件，直接卡死或报 Relay log read failure。
正确流程是：
- 先执行
STOP SLAVE;，再用SHOW PROCESSLIST确认没有Slave_IO_Running进程残留 - 立刻执行
RESET SLAVE ALL;（注意带ALL）——它会清空master.info、relay-log.info，删除所有 relay log 文件，并把Relay_Log_File设为空、Relay_Log_Pos设为4 - 不带
ALL的RESET SLAVE只重置内存变量，旧损坏或缺失的文件还在磁盘上，后续START SLAVE仍会失败
重设起点必须用主库当前 binlog 位点，不是“大概位置”
RESET SLAVE ALL 后，从库彻底“忘记”自己同步到哪了。不能靠 CHANGE MASTER TO 指向旧位置，否则可能漏事件或重复执行。
操作步骤：
- 在主库执行
SHOW MASTER STATUS\G，记下File（如mysql-bin.000123）和Position（如456789） - 在从库执行：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=456789;
注意：文件名加单引号，位置值不加引号 - 如果主库启用了 GTID，不要设
MASTER_LOG_FILE/MASTER_LOG_POS，改用：SET GLOBAL gtid_slave_pos = 'uuid:1-100';<br>CHANGE MASTER TO ENABLE_GTID = 1;
执行完立刻 START SLAVE;，再用 SHOW SLAVE STATUS\G 看 Slave_SQL_Running 是否变 Yes、Seconds_Behind_Master 是否开始下降。
relay_log_recovery=ON 不是万能药，开不对等于没开
这个参数只在 MySQL 启动时生效，且依赖两个前提：master_info_repository=TABLE 和 relay_log_info_repository=TABLE。如果仍是默认的 FILE 模式，relay_log_recovery=ON 实际不工作。
验证方式：
SHOW VARIABLES LIKE '%repository%';两个值都必须是
TABLE。另外，该参数是动态变量，但修改后必须重启 mysqld 才会触发恢复逻辑。
更现实的情况是：你发现故障时，relay_log_recovery 一直是关闭的，又刚删了 relay log——这时唯一安全路径就是上面三步：停、重置、对齐主库位点。别指望配置一开就自动修好。
