1. 问题现象与背景分析最近在GreatSQL数据库运维中遇到一个典型问题异步复制架构下从库的IO线程突然中断报错显示主库已清除从库所需的二进制日志。具体错误信息如下2026-02-16T12:36:40.08662008:00 12452 [ERROR] [MY-010557] [Repl] Error reading packet from server for channel :Cannot replicate because the master purged required binary logs...这个报错表面看是主库binlog过期导致但深入分析发现根本原因是slave_skip_errorsALL这个危险参数设置。作为DBA我们需要理解GreatSQL的异步复制机制中IO线程负责从主库拉取binlog事件SQL线程负责应用这些事件当slave_skip_errorsALL时从库会跳过所有错误继续复制导致主从数据不一致的风险主库binlog_expire_logs_seconds6048007天的配置其实已经比较合理2. 问题根因深度解析2.1 GTID空洞的形成机制通过分析error.log发现从库的GTID集合存在明显空洞8451fc4d-d1ae-11ec-b2bf-5254002b8928:1-19789717:19789719-20046740缺少的事务19789718被跳过但后续事务继续执行。这种跳事务现象直接源于slave_skip_errorsALL的配置。2.2 slave_skip_errors参数的危险性该参数默认值为OFF主要作用包括参数值行为风险等级OFF遇到任何错误停止复制安全ALL跳过所有错误继续复制高危错误代码列表跳过指定错误继续复制中等当设置为ALL时以下危险场景可能发生主键冲突被跳过 → 数据不一致DDL执行失败被跳过 → 表结构不一致锁等待超时被跳过 → 业务逻辑错误3. 完整复现实验3.1 实验环境搭建配置主从复制集群-- 主库配置 [mysqld] server-id1 log-binmysql-bin binlog_formatROW binlog_expire_logs_seconds604800 gtid_modeON enforce_gtid_consistencyON -- 从库危险配置 [mysqld] server-id2 slave_skip_errorsALL -- 关键问题参数 slave_parallel_workers83.2 问题复现步骤在主库创建测试表并插入数据CREATE TABLE test1 ( id INT PRIMARY KEY, k INT, c VARCHAR(100), pad VARCHAR(100) ); INSERT INTO test1 VALUES(2, 50248, init_value, REPEAT(a,100));在从库开启事务并锁定行BEGIN; UPDATE test1 SET cslave_lock WHERE id2; -- 不提交在主库更新同一行UPDATE test1 SET cmaster_value WHERE id2;通过sysbench在主库持续产生负载sysbench oltp_read_write --db-drivermysql --mysql-hostmaster_host run3.3 监控与结果分析观察从库状态SHOW SLAVE STATUS\G SELECT gtid_executed;会发现GTID出现空洞如1-100:102-200从库error.log中有锁超时警告但复制继续主从数据不一致但复制状态仍显示正常4. 问题修复方案4.1 紧急恢复措施当IO线程已中断时-- 1. 重建复制关系 STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO ... -- 重新配置 START SLAVE; -- 2. 数据校验修复 使用pt-table-checksum校验数据差异 使用pt-table-sync修复差异数据4.2 根本解决方案修改危险参数SET GLOBAL slave_skip_errors; -- 恢复默认值OFF配置复制监控-- 监控GTID连续性 SELECT GTID_SUBTRACT(gtid_executed, gtid_purged) AS gtid_gap; -- 监控复制延迟 SHOW SLAVE STATUS\G建议配置[mysqld] slave_skip_errors # 保持为空 slave_exec_modeSTRICT # 严格模式 replica_parallel_workers8 # 并行复制 replica_parallel_typeLOGICAL_CLOCK # 基于事务的并行5. 生产环境最佳实践5.1 参数配置规范参数推荐值说明slave_skip_errorsOFF必须保持默认binlog_expire_logs_seconds1209600适当延长binlog保存时间replica_parallel_workers4-16根据CPU核心数调整sync_binlog1确保binlog持久化5.2 监控体系搭建建议部署以下监控项GTID连续性监控每分钟检查主从数据校验每天全量检查复制延迟告警阈值60秒SQL线程错误监控示例Prometheus监控规则- alert: GreatSQLReplicationError expr: mysql_slave_status_slave_sql_running 0 for: 1m labels: severity: critical annotations: summary: GreatSQL复制SQL线程停止 (instance {{ $labels.instance }}) description: Slave SQL thread has stopped on {{ $labels.instance }}6. 经验总结与教训永远不要设置slave_skip_errorsALL这个参数相当于关闭了复制的安全机制允许数据静默不一致。曾经有生产案例因此导致财务对账差异达数百万元。并行复制的锁冲突处理实验中发现当slave_parallel_workers1时锁等待超时更容易发生。建议适当增加innodb_lock_wait_timeout默认50秒为长时间运行的事务添加提示/* NO_PARALLEL */binlog保留策略虽然本例中7天的binlog保留期是合理的但对于以下场景建议延长跨地域复制超大事务频繁的系统备份周期较长的环境故障恢复的黄金法则当出现复制中断时正确的处理流程应该是1. 停止业务写入 2. 记录故障现场SHOW SLAVE STATUS, error.log 3. 分析根本原因 4. 制定恢复方案数据修复或重建复制 5. 验证数据一致性 6. 恢复业务最后特别提醒GreatSQL作为MySQL分支虽然增强了并行复制等特性但复制基本原理相同。任何跳过错误继续复制的操作都是危险的必须通过数据修复来解决根本问题。