确认relay log真损坏需先查SHOW SLAVE STATUS\G：Slave_IO_Running为Yes但Slave_SQL_Running为No，且Last_SQL_Error含“Could not parse relay log event entry”、Seconds_Behind_Master为NULL、Relay_Log_Pos停滞；再用mysqlbinlog解析当前Relay_Log_File，报Invalid replication event即坐实损坏。
确认是不是 relay log 真损坏，别一上来就删文件
看到 Last_SQL_Error 里有 Relay log read failure 或 Could not parse relay log event entry，先别动手。关键看 SHOW SLAVE STATUS\G 里：Slave_IO_Running: Yes 但 Slave_SQL_Running: No，且 Seconds_Behind_Master 是 NULL、Relay_Log_Pos 长期不动——这才大概率是 relay log 本身坏了。
验证方法很简单：mysqlbinlog /var/lib/mysql/hostname-relay-bin.000123 | head -n 20，如果报 Invalid replication event 或直接段错误，坐实损坏。如果 Slave_IO_Running: No，那问题在连接主库、权限或主库 binlog 被删，跟 relay log 无关。
STOP SLAVE 后必须用 RESET SLAVE ALL，不能只删文件
手动 rm -f hostname-relay-bin.* 是最危险操作：MySQL 不会自动重建有效 relay log，SQL 线程启动时会卡在非法偏移，甚至跳过事务。
正确做法是：
- 先执行
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仍会加载失败
从主库拿真实位点，用 CHANGE MASTER TO 重设起点
RESET SLAVE ALL 后，从库“忘记”自己同步到哪了。必须从主库查最新坐标，否则会重复执行或漏事件。
在主库执行：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';，再CHANGE MASTER TO ENABLE_GTID = 1;
START SLAVE;，然后 SHOW SLAVE STATUS\G 看 Slave_SQL_Running 是否变 Yes、Seconds_Behind_Master 是否开始下降。relay-log.index 损坏要单独处理，不能指望 RESET SLAVE ALL
如果 MySQL 启动失败，日志里报 Failed to open the relay log index file，或者 SHOW SLAVE STATUS\G 显示 Relay_Log_File 为空，大概率是 relay-log.index 文件损坏。RESET SLAVE ALL 不会重建这个索引文件，必须手动处理：
- 先
STOP SLAVE;，确认无Slave_IO_Running进程 - 查
SELECT @@datadir;和SELECT @@relay_log_basename;，进入对应目录 - 运行
ls -1v hostname-relay-bin.[0-9]* > relay-log.index（-v确保版本号自然排序） - 用
head -n 3 relay-log.index核对前几行是否为合法文件名，末尾不能有空行
START SLAVE;，重点看 Relay_Log_File 是否指向索引最后一行的文件，且 Relay_Log_Pos > 4。 
