relay log损坏必须停复制后基于主库真实位点重建SQL线程起点，不可跳过或直接删除文件；先确认是否真损坏，再通过RESET SLAVE ALL清状态，最后用CHANGE MASTER TO重设位点。
relay log 损坏不能跳过、不能删完重启，必须停复制后基于主库真实位点重建 SQL 线程起点；否则大概率丢数据或主从错位。
确认是不是 relay log 真损坏，不是 IO 线程问题
很多人一看到 Relay log read failure 就动手删文件，结果发现根本不是 relay log 的事。先分清责任归属：
-
Slave_IO_Running: No且Last_IO_Error含error connecting to master或Could not find first log file name→ 是网络、权限或主库 binlog 被删，跟 relay log 无关 -
Slave_IO_Running: Yes但Slave_SQL_Running: No，Last_SQL_Error明确报Could not parse relay log event entry或log event entry exceeded max_allowed_packet→ 才是 relay log 解析失败 - 用
mysqlbinlog /var/lib/mysql/hostname-relay-bin.000123 | head -n 20手动解析当前Relay_Log_File：若直接报Failed to open file或Invalid replication event，才坐实损坏
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仍会加载失败
从主库查真实 binlog 位点，用 CHANGE MASTER TO 重定向
RESET 之后，从库“忘记”自己同步到哪了，必须从主库拿最新坐标，否则会重复执行或漏事件。
- 在主库执行
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_recovery 和 relay_log_info_repository=TABLE
每次靠人工恢复既慢又易错。真正有效的防御是让 MySQL 自己扛住异常中断。
-
relay_log_recovery=ON必须开启，但它只在 mysqld 启动时生效 —— 前提是relay_log_info_repository=TABLE且master_info_repository=TABLE，否则无法准确定位已执行位置 -
sync_relay_log=1强制每次写 relay log 都刷盘，避免断电导致半写文件 -
relay_log_purge=OFF在高负载或频繁重启场景下建议关闭，防止 SQL 线程刚执行完一个文件、IO 线程正写下一个时发生冲突错乱
最容易被忽略的是：relay_log_recovery 不是“热修复开关”，它只在进程启动那一刻起作用；而 RESET SLAVE ALL 后不查主库真实位点就 START SLAVE，等于让从库从头拉取，业务表可能被重复插入或丢失中间状态。
