relay-log.info文件损坏会导致SHOW SLAVE STATUS中Relay_Log_File和Relay_Log_Pos为空或错乱、Seconds_Behind_Master为NULL、Slave_SQL_Running为No，并出现相关错误日志。
relay-log.info 文件损坏会导致什么现象
relay-log.info 损坏时，SHOW SLAVE STATUS\G 里 Relay_Log_File 和 Relay_Log_Pos 通常为空或明显错乱，Seconds_Behind_Master 变为 NULL，Slave_SQL_Running 直接为 No，错误日志可能出现 Failed to open the relay log info file 或 Could not read relay log info。注意：这不是 relay log 文件本身损坏，而是记录“当前执行到哪个中继日志、哪个偏移”的元数据文件坏了。
不能用 RESET SLAVE ALL 清除 relay-log.info
RESET SLAVE ALL 会删除 relay-log.info，但它同时清空 master.info、所有 relay log 文件和复制坐标，导致从库彻底“失忆”——你将无法知道 IO 线程最后拉到了主库哪个位置，后续 CHANGE MASTER TO 容易设错，造成漏事件或重复执行。更糟的是，如果 relay_log_info_repository=FILE（默认），MySQL 启动后不会自动重建该文件，复制直接卡死。
- 只在确认
relay_log_info_repository=TABLE且已停库的情况下，才可考虑删文件 + 重启 - 若仍用文件存储，必须手动修复，不能依赖
RESET SLAVE - 检查方式：
SHOW VARIABLES LIKE 'relay_log_info_repository';，值为FILE才需本节操作
手动重建 relay-log.info 的安全步骤
核心是让文件内容严格匹配当前磁盘上有效的 relay log 文件序列，并指向 SQL 线程应继续读取的位置。操作前必须 STOP SLAVE 并确认无 Slave_IO_Running 进程。
- 查出 relay log 前缀：
SELECT @@relay_log_basename;（如/var/lib/mysql/myhost-relay-bin） - 进对应目录：
cd /var/lib/mysql，运行ls -1v myhost-relay-bin.[0-9]* > relay-log.info（-v确保 000010 排在 00002 后） - 编辑
relay-log.info，确保第一行是最新 relay log 文件的绝对路径（如/var/lib/mysql/myhost-relay-bin.000042），第二行填4（起始偏移），第三四行留空或填0（MySQL 5.7+ 兼容格式） - 检查权限：
chown mysql:mysql relay-log.info，chmod 644 relay-log.info
启动后必须验证的三个点
文件写完不等于生效。MySQL 加载它有隐式规则，容易被忽略：
-
START SLAVE;后立刻执行SHOW SLAVE STATUS\G，确认Relay_Log_File已加载为你刚写的那个文件名，且Relay_Log_Pos > 4 - 查错误日志，排除
Could not find target log during relay log initialization—— 这说明relay-log.info里写的文件名在磁盘上不存在 - 运行
SELECT @@relay_log_index;，输出必须和relay-log.info路径一致；若为空，说明my.cnf里没配relay_log_index或配置未生效
真正麻烦的不是重建文件，而是路径、权限、版本号排序这三处细节稍有偏差，MySQL 就静默失败，连错误日志都不报。
