确认relay-log真损坏需先查show slave status\g：slave_io_running为yes但slave_sql_running为no，且last_sql_error含“corrupted replication event”等提示；再用mysqlbinlog解析当前relay_log_file，报invalid replication event即坐实损坏。
Relay log读取失败报错怎么确认真是损坏
看到Relay log read failure或Could not parse relay log event entry，别急着删文件。先看SHOW SLAVE STATUS\G里：Slave_IO_Running: Yes但Slave_SQL_Running: No，且Last_SQL_Error含Corrupted replication event或log event entry exceeded max_allowed_packet，才大概率是relay log真坏了。Seconds_Behind_Master变成NULL、Relay_Log_File和Relay_Log_Pos长期不动，也是典型表现。
验证手段：用mysqlbinlog解析当前Relay_Log_File路径下的文件，比如mysqlbinlog /var/lib/mysql/hostname-relay-bin.000042 | head -20。若报Invalid replication event或直接段错误，基本坐实损坏。
relay-log.index损坏导致MySQL启动失败怎么办
relay-log.index损坏时，错误日志里会出现Failed to open the relay log index file，SHOW SLAVE STATUS中Relay_Log_File为空，甚至MySQL根本起不来。这时不能RESET SLAVE——它会清空所有复制元数据，但不会重建索引文件。
安全重建步骤：
- 先执行
STOP SLAVE，再确认ps aux | grep mysql里没有Slave_IO_Running进程 - 查
SELECT @@datadir拿到数据目录，cd进去；再查SELECT @@relay_log_basename确认前缀（默认是主机名+-relay-bin） - 运行
ls -1v hostname-relay-bin.[0-9]* > relay-log.index（-v确保版本号自然排序，避免000010排在00002前面） - 检查
head -n 3 relay-log.index是否全是合法文件名，末尾不能有空行
relay_log_recovery=ON为什么必须静态配置
relay_log_recovery=ON是唯一能自动丢弃损坏relay log并从master.info或GTID位点重建的机制，但它只在MySQL启动时生效。动态执行SET GLOBAL relay_log_recovery = ON完全无效。
必须把它写进/etc/my.cnf的[mysqld]段里，然后重启mysqld。重启后，MySQL会自动跳过损坏的relay log，从IO线程最后成功记录的位置重拉binlog——这不是跳过，而是重建。
注意：relay_log_recovery=ON在GTID模式下依赖enforce_gtid_consistency=ON和gtid_mode=ON才能准确定位起点；如果主库binlog已被清理，它会直接报错，不强行伪造位置。
手动重置SQL线程起点时Master_Log_Pos怎么取
不能抄主库当前SHOW MASTER STATUS的Position，那是最新位置，从库很可能没消费到那里。正确值来自SHOW SLAVE STATUS\G里的Master_Log_File和Master_Log_Pos——这是IO线程已成功拉取但尚未执行的最远坐标，是唯一可信的“已同步到哪”的标记。
操作链必须严格按顺序：
STOP SLAVE- 记下
Master_Log_File（如mysql-bin.000123）和Master_Log_Pos（如456789） -
RESET SLAVE（清空所有relay log文件和relay-log.index） CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=456789START SLAVE
如果原是GTID模式，RESET SLAVE ALL后得用SET GLOBAL gtid_purged='xxx'和CHANGE MASTER TO MASTER_AUTO_POSITION=1，而不是填文件和位置。
最容易被忽略的是：RESET SLAVE之后Relay_Master_Log_File和Exec_Master_Log_Pos会被清空，但Master_Log_File/Master_Log_Pos保留——这正是你后续CHANGE MASTER TO的依据。别误以为它们也丢了。
