怎么解决MySQL主从复制中的1594错误_修复relay-log-info文件损坏-mysql教程-PHP中文网

1594错误本质是relay log文件损坏，而非relay-log.info问题；其触发于mysqlbinlog解析中继日志时crc校验失败，需通过relay_log_recovery=on重启恢复或手动用master_log_file+read_master_log_pos重置。

怎么解决mysql主从复制中的1594错误_修复relay-log-info文件损坏

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。整个过程不依赖人工判断位点，也不丢事务。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

必须写进配置文件（如 /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 线程落后很多，会导致重复执行或跳过事务