1594错误本质是relay log物理文件损坏，需通过mysqlbinlog验证（报Invalid replication event等）；确认后首选启用relay_log_recovery=ON并重启mysqld自动重建，不可动态设置；无法停服时则用Master_Log_File+Read_Master_Log_Pos手动重置SQL线程起点。
1594 错误不是配置问题或权限问题，而是从库的 relay log 文件物理损坏——mysqlbinlog 解析时明确报 Event crc check failed 或 Invalid replication event，必须重建 relay log，不能跳过、不能修 relay-log.info。
怎么确认真是 relay log 损坏，而不是 IO 线程没拉到新日志？
先看 SHOW SLAVE STATUS\G 输出：
-
Slave_IO_Running: Yes且Read_Master_Log_Pos在持续增长 → IO 线程正常，问题在 SQL 线程解析环节 -
Slave_SQL_Running: No+Last_Errno: 1594+Last_Error含Could not parse relay log event entry→ 高概率是 relay log 文件损坏 - 用
mysqlbinlog手动验证：mysqlbinlog /var/lib/mysql/mysql-relay-bin.000042（路径和文件名来自Relay_Log_File字段）；若报Failed to open file、Invalid replication event或直接退出，坐实损坏 - 注意：
relay-log.info出问题通常表现为ERROR 1236（找不到 relay log 文件），不是 1594
首选方案：启用 relay_log_recovery=ON 并重启 mysqld
这是唯一能自动丢弃损坏 relay log 并安全重建的机制，不是“跳过”，而是从 master.info 或 GTID 位点重新拉取 binlog 生成新 relay log：
- 必须写进配置文件（如
/etc/my.cnf的[mysqld]段），加一行：relay_log_recovery=ON -
SET GLOBAL relay_log_recovery = ON完全无效，动态设置不触发任何恢复逻辑 - 修改后必须
systemctl restart mysqld（或service mysql restart），仅STOP/START SLAVE不会生效 - GTID 模式下需确保
gtid_mode=ON且enforce_gtid_consistency=ON，否则无法准确定位重拉起点 - 该方案不依赖人工判断位点，也不丢事务，但前提是主库 binlog 本身完好
不能停服时：手动重置 SQL 线程起点
适用于生产环境不允许重启 MySQL，且未提前启用 relay_log_recovery 的场景。核心是放弃损坏的 relay log，但复用 IO 线程已拉取的最新位点：
- 执行
STOP SLAVE;（停全部线程） - 记录
Master_Log_File和Read_Master_Log_Pos—— 这两个值代表“IO 线程已成功拉到主库哪”，是唯一可信坐标 - 执行
RESET SLAVE;（清空所有 relay log 文件及索引，重置Relay_Master_Log_File和Exec_Master_Log_Pos） - 若原为 GTID 模式，先关位置模式：
CHANGE MASTER TO MASTER_AUTO_POSITION = 0;；否则会报ERROR 1776 - 用刚才记下的值重定向：
CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000123', MASTER_LOG_POS = 456789; - 再启动：
START SLAVE SQL_THREAD;（可先不启 IO 线程，避免重复拉取）
最易被忽略的一点：Relay_Log_File 和 Relay_Log_Pos 是损坏状态下的非法位置，绝不能拿来用；真正可用的只有 Master_Log_File + Read_Master_Log_Pos。误用前者会导致跳过已拉取但未执行的事务，造成主从数据断裂。
