relay log read failure是relay log文件损坏的明确信号，需停复制后用change master to跳过损坏文件，并启用relay_log_recovery=on和sync_relay_log=1预防；跳过后须结合主库binlog校验并人工补漏以保障数据一致性。
Relay log read failure 就是 relay log 文件损坏的明确信号，不是网络或权限问题，直接按日志损坏处理。
确认确实是 relay log 损坏而非其他原因
看到 Last_Error: Relay log read failure: Could not parse relay log event entry，且伴随 Seconds_Behind_Master 为 NULL、Slave_SQL_Running 为 No、Relay_Log_Pos 停滞不动，基本可排除主库 binlog 问题或网络中断。
此时应优先验证从库本地的 relay log 是否能被解析：
- 从
SHOW SLAVE STATUS\G中提取Relay_Log_File（如mysqld-relay-bin.000121） - 运行
mysqlbinlog /var/lib/mysql/mysqld-relay-bin.000121 | head -n 20—— 若报unknown binlog event type或直接崩溃，即确认损坏 - 不要只查
Relay_Master_Log_File和Exec_Master_Log_Pos，那是主库位点，和 relay log 是否损坏无关
STOP SLAVE 后用 CHANGE MASTER TO 跳过损坏文件
不能删文件再 START SLAVE，MySQL 不会自动重建 relay log，反而报 Failed to open the relay log。安全做法是显式重定向复制起点：
- 若未启用 GTID：查出下一个 relay log 文件名（例如当前坏的是
mysqld-relay-bin.000121，则下一个是mysqld-relay-bin.000122），位置设为4 - 执行
CHANGE MASTER TO RELAY_LOG_FILE='mysqld-relay-bin.000122', RELAY_LOG_POS=4，再START SLAVE - GTID 模式下
sql_slave_skip_counter完全失效，且CHANGE MASTER TO不能混用MASTER_LOG_FILE和RELAY_LOG_FILE参数 - 手动指定 relay log 起点时，务必确认下一个文件真实存在且能被
mysqlbinlog解析，否则START SLAVE会立即失败
误删 relay-log 文件后必须用 Read_Master_Log_Pos 重设
删了 relay-log 后，Relay_Master_Log_File 和 Exec_Master_Log_Pos 已失效，不能拿来重设。唯一可信的是 IO 线程当前拉到的位置 —— 即 Master_Log_File 和 Read_Master_Log_Pos：
- 记下
SHOW SLAVE STATUS\G中的Master_Log_File（如mysql-bin.001078）和Read_Master_Log_Pos（如670812995） - 执行
RESET SLAVE—— 它会清空所有 relay-log 文件、重置relay-log.index，但不碰Master_Log_File/Read_Master_Log_Pos - 执行
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.001078', MASTER_LOG_POS=670812995 - GTID 模式需先执行
CHANGE MASTER TO MASTER_AUTO_POSITION = 0，否则报错ERROR 1776
预防比修复更重要：必须开启 relay_log_recovery 和 sync_relay_log
relay log 损坏多由异常断电、kill 线程或误删文件引发，靠人工恢复既慢又易出错：
-
relay_log_recovery=ON：MySQL 启动时自动检测并丢弃不完整的 relay log，重建新文件 -
sync_relay_log=1：每次写入 relay log 都强制刷盘，避免缓存丢失 - 额外建议：
relay_log_info_repository=TABLE（替代文件存储位点），配合sync_relay_log_info=1，防止位点丢失导致跳过错误
跳过损坏 relay log 后无法默认信任数据一致，因为至少有一段主库变更没被从库执行；必须结合主库 mysqlbinlog 校验对应位置附近事件，并人工补漏 —— 这个步骤最容易被跳过，但恰恰是线上恢复中最关键的一环。
