Relay log read failure 是 relay log 文件损坏的明确信号，需按日志损坏处理：先停复制，再通过 CHANGE MASTER TO 或 GTID 跳过损坏文件，并启用 relay_log_recovery=ON 和 sync_relay_log=1 预防。
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 是否损坏无关
跳过损坏 relay log 的两种路径（必须停复制后操作）
不能删文件再 start slave，MySQL 不会自动重建 relay log，反而报 Failed to open the relay log。安全做法是显式重定向复制起点：
- 执行
STOP SLAVE - 若未启用 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 - 若已启用 GTID：
SET GTID_NEXT='xxx-xxx-xxx:yyy'; BEGIN; COMMIT;（其中 yyy 是Exec_Master_Log_Pos对应事务的 GTID 序号），再START SLAVE；sql_slave_skip_counter在 GTID 模式下完全失效
预防比修复更重要：关键配置项必须开启
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，防止位点丢失导致跳过错误
GTID 模式下跳过逻辑完全不同，且 CHANGE MASTER TO 不能混用 MASTER_LOG_FILE 和 RELAY_LOG_FILE 参数；手动指定 relay log 起点时，务必确认下一个文件真实存在且可被 mysqlbinlog 解析，否则 start slave 会立即失败。
