1594错误本质是中继日志文件crc校验失败导致解析中断，非单事件错误，故sql_slave_skip_counter无效；唯一安全方案是启用relay_log_recovery=on重启重建，或手动以master_log_file和read_master_log_pos重设起点。
1594错误不能“强制跳过”，只能“重建中继日志”——因为根本不是某条事件错了，而是整个mysql-relay-bin.xxxxx文件CRC校验失败，解析器直接拒读。
为什么sql_slave_skip_counter=1对1594完全无效
这个参数只影响SQL线程在执行事件时的计数器，而1594发生在事件解析阶段（mysqlbinlog读取relay log文件时就报Event crc check failed），SQL线程压根没机会启动。执行后仍报错，还可能让SQL线程从损坏文件开头重试，反复失败。
-
Last_Error里明确含Relay log read failure: Could not parse relay log event entry，关键词是parse relay log，不是execute - 用
mysqlbinlog /var/lib/mysql/mysql-relay-bin.000042手动解析该文件，会直接报Invalid replication event或CRC32 mismatch -
relay-log.info只是记录位置的元数据，删了它或改错值只会让SQL线程指向非法偏移，不解决文件级损坏
首选方案：relay_log_recovery=ON必须静态配置并重启
这是MySQL唯一内置的安全重建机制：启动时检测到SQL线程异常退出，自动丢弃所有不完整的relay log文件，并从master.info或GTID位点重新拉取主库binlog生成新relay log。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 必须写进
/etc/my.cnf的[mysqld]段：relay_log_recovery=ON，SET GLOBAL relay_log_recovery = ON动态设置无效 - 修改后必须
systemctl restart mysqld（或service mysql restart），仅STOP/START SLAVE不触发恢复逻辑 - GTID模式下需同时确认
enforce_gtid_consistency=ON和gtid_mode=ON，否则无法准确定位重拉起点 - 该操作不丢事务——IO线程已拉取但未执行的事件，会从正确位点重传
无法重启时的手动重建步骤（慎用）
前提：IO线程仍在运行（Slave_IO_Running: Yes），且Read_Master_Log_Pos持续增长，说明主库日志还在接收中。
- 记下
SHOW SLAVE STATUS\G中的Master_Log_File和Read_Master_Log_Pos（这是IO线程最新读到的位置，不是损坏的relay log位置） - 停SQL线程：
STOP SLAVE SQL_THREAD;（保留IO线程继续拉日志） - 清空relay log：
RESET SLAVE;（RESET SLAVE ALL会清空连接信息，非必要不用） - 重设复制起点：
CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy;（用上一步记下的值） - 若原为GTID模式，先执行：
SET GLOBAL gtid_purged='';，再CHANGE MASTER TO MASTER_AUTO_POSITION=1; - 启动SQL线程：
START SLAVE SQL_THREAD;
容易被忽略的关键点
很多人卡在“为什么RESET SLAVE后START SLAVE还是报1594”——因为没停SQL线程就重置，或者重置后没用Master_Log_File+Read_Master_Log_Pos重新定位，而是沿用了旧的Relay_Log_File路径。更隐蔽的是：某些系统启用了master_info_repository=TABLE，RESET SLAVE不会清空内存里的master info，必须确认SHOW SLAVE STATUS里Master_Host等字段是否仍有效。
