如何分析MySQL从库报错Relay log read failure中继日志损坏并进行恢复？

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 是否能被解析：

1. 从 SHOW SLAVE STATUSG 中提取 Relay_Log_File（如 mysqld-relay-bin.000121）
2. 运行 mysqlbinlog /var/lib/mysql/mysqld-relay-bin.000121 | head -n 20 —— 若报 unknown binlog event type 或直接崩溃，即确认损坏
3. 不要只查 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。安全做法是显式重定向复制起点：

1. 若未启用 GTID：查出下一个 relay log 文件名（例如当前坏的是 mysqld-relay-bin.000121，则下一个是 mysqld-relay-bin.000122），位置设为 4
2. 执行 CHANGE MASTER TO RELAY_LOG_FILE='mysqld-relay-bin.000122', RELAY_LOG_POS=4，再 START SLAVE
3. GTID 模式下 sql_slave_skip_counter 完全失效，且 CHANGE MASTER TO 不能混用 MASTER_LOG_FILE 和 RELAY_LOG_FILE 参数
4. 手动指定 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：

1. 记下 SHOW SLAVE STATUSG 中的 Master_Log_File（如 mysql-bin.001078）和 Read_Master_Log_Pos（如 670812995）
2. 执行 RESET SLAVE —— 它会清空所有 relay-log 文件、重置 relay-log.index，但不碰 Master_Log_File / Read_Master_Log_Pos
3. 执行 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.001078', MASTER_LOG_POS=670812995
4. GTID 模式需先执行 CHANGE MASTER TO MASTER_AUTO_POSITION = 0，否则报错 ERROR 1776

预防比修复更重要：必须开启 relay_log_recovery 和 sync_relay_log

relay log 损坏多由异常断电、kill 线程或误删文件引发，靠人工恢复既慢又易出错：

1. relay_log_recovery=ON：MySQL 启动时自动检测并丢弃不完整的 relay log，重建新文件
2. sync_relay_log=1：每次写入 relay log 都强制刷盘，避免缓存丢失
3. 额外建议：relay_log_info_repository=TABLE（替代文件存储位点），配合 sync_relay_log_info=1，防止位点丢失导致跳过错误

跳过损坏 relay log 后无法默认信任数据一致，因为至少有一段主库变更没被从库执行；必须结合主库 mysqlbinlog 校验对应位置附近事件，并人工补漏 —— 这个步骤最容易被跳过，但恰恰是线上恢复中最关键的一环。