1594错误本质是relay log文件损坏，而非relay-log.info问题；其触发于mysqlbinlog解析中继日志时CRC校验失败，需通过relay_log_recovery=ON重启恢复或手动用Master_Log_File+Read_Master_Log_Pos重置。
1594 错误本质是 relay log 文件损坏，不是 relay-log-info 文件问题；直接修 relay-log-info 不但无效，还会让 SQL 线程指向非法位置，导致数据丢失。
为什么不是 relay-log-info 损坏导致 1594
错误日志里明确提示 Relay log read failure: Could not parse relay log event entry，重点在「parse relay log」——即解析中继日志文件本身失败。MySQL 报错 1594 的触发点是 mysqlbinlog 解析 Relay_Log_File（如 mysql-relay-bin.000042）时 CRC 校验失败或读取异常，跟记录位置的元数据文件 relay-log.info 无关。
relay-log.info 只存当前 SQL 线程执行到哪个 relay log 文件和偏移量（Relay_Log_File / Relay_Log_Pos），它不参与事件解析；即使该文件被删或写坏，MySQL 启动时也能从 slave_relay_log_info 表（如果启用了表存储）或自动重建，不会引发 1594。
- 真正损坏的是
Relay_Log_File对应的物理文件（例如/var/lib/mysql/mysql-relay-bin.000042） - 用
mysqlbinlog /path/to/relay-log-file尝试解析，若报Invalid replication event或Event crc check failed，就坐实了 relay log 文件级损坏 -
relay-log.info出问题通常表现为START SLAVE报ERROR 1236（找不到 relay log 文件）或 SQL 线程启动后立即停止，而非 1594
relay_log_recovery=ON 是唯一安全的自动恢复方式
这个参数不是“跳过”错误，而是在 MySQL 启动时检测到 SQL 线程异常退出后，自动丢弃所有不完整的 relay log 文件，并从 master.info 或 GTID 位点重新拉取主库 binlog 建立新 relay log。整个过程不依赖人工判断位点，也不丢事务。
- 必须写进配置文件（如
/etc/my.cnf的[mysqld]段），SET GLOBAL relay_log_recovery = ON动态设置完全无效 - 修改后必须重启
mysqld，仅STOP/START SLAVE不会触发恢复逻辑 - GTID 模式下需确保
enforce_gtid_consistency=ON和gtid_mode=ON，否则无法准确定位重拉起点 - 如果主库 binlog 已损坏，此参数无用——它只解决从库 relay log 损坏，不修复源头
不能重启 MySQL 时，手动重置必须用 Master_Log_File + Read_Master_Log_Pos
当生产环境不允许停服，且未启用 relay_log_recovery，只能手动干预。关键原则：放弃损坏的 relay log，但绝不丢弃已由 IO 线程拉取、尚未执行的事件。
- 先确认
Slave_IO_Running: Yes，说明 IO 线程仍在工作；记下SHOW SLAVE STATUS\G中的Master_Log_File（如mysql-bin.000123）和Read_Master_Log_Pos（如456789）——这是 IO 线程最新拉到的位置，可信 - 执行
STOP SLAVE;，再RESET SLAVE;（不是RESET SLAVE ALL，后者会清空连接信息，GTID 模式下可能引发ERROR 1776） - 检查
MASTER_AUTO_POSITION：若为1，直接START SLAVE;即可；若为0，才需CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=456789; - 切勿用
Exec_Master_Log_Pos或Relay_Master_Log_File定位——它们指向已执行完的位置，可能比 IO 线程落后很多，会导致重复执行或跳过事务
最容易被忽略的点：别信 Last_SQL_Error 里的“possible reasons”
报错信息末尾那句 The possible reasons are: the master's binary log is corrupted... 是通用模板，不是诊断结论。实际 99% 的 1594 都是 relay log 本地损坏，主库 binlog 完好。
验证主库 binlog 是否真损坏，只需在主库执行 mysqlbinlog /path/to/master-bin.000123 | tail -20；若能正常输出，就排除主库问题。盲目去主库重置 binlog 或 dump 全量数据，只会扩大故障面。
