1. 凌晨三点的主从中断手动处理的成本到底有多高我先说一个真实场景。凌晨两点五十七分手机震了告警平台上一条P2消息某业务从库的Slave_SQL_Running变成No。你爬起来打开电脑登录从库敲一句SHOW SLAVE STATUS\G看到Last_SQL_Error是Error Duplicate entry 10086 for key PRIMARY on query也就是1062主键冲突。常规操作就来了分析这条报错评估能不能跳过确认跳过之后会不会造成数据不一致然后STOP SLAVE、SET GLOBAL sql_slave_skip_counter1、START SLAVE再观察Seconds_Behind_Master能不能追到0。运气好十几分钟收工运气不好跳过之后又报下一条你整个人就麻了。这就是MySQL主从运维里最常见的夜班噩梦。主从复制本质上是一个不断从主库拉取binlog、写入relay log、再在从库回放的过程任何一个环节出问题复制线程就会停下而它不会自己恢复。传统做法是人工介入看错误、判断影响、执行修复。问题在于故障类型翻来覆去就那么几类处理手法高度重复但因为每一条错误背后可能藏着不一致的隐患没人敢直接写个脚本粗暴地sql_slave_skip_counter1一路跳过去。但也正因为如此这件事可以做得比大部分人想象中更自动、更安全。我花了大半年时间把一个手动处理主从报错的流程逐步重构成了一个带诊断、分类、修复、自检、熔断的自动化工具内部代号叫repl-healer。这篇文章把我整个设计思路和踩坑经历写出来适合正在被MySQL主从报错折磨的运维同学、刚接手从库管理的DBA以及那些想给自己手头一坨实例找条出路的兼职运维。不说大而全的治理方案只说一件事主从报错到底能不能自动修怎么修才不会把数据修出更大的坑。1.1 主从中断最常见的三类故障IO线程、SQL线程与延迟积压要谈自动修复先得把故障分清楚。SHOW SLAVE STATUS里面有两根关键的线程状态Slave_IO_Running和Slave_SQL_Running。我见过不少刚入行的同事只看这两个字段是不是Yes但其实故障至少分三类。第一类IO线程断连。表象是Slave_IO_Running: Connecting或者NoLast_IO_Error往往指向网络超时、主库连接数打满、主库重启、甚至主从之间binlog位置失效。这类故障通常不影响从库上的既有数据修复动作相对安全以重连、重新拉取binlog为主。我遇到过的典型错误是Got fatal error 1236 from master when reading data from binary log: Could not find first log file name in binary log index第一次碰上那真是冷汗直冒后面才知道这大多是从库的relay log被清理、主库binlog被purge或者change master时指定的MASTER_LOG_FILE已经不存在了。第二类SQL线程报错这是最麻烦的一类。表现为Slave_SQL_Running: NoLast_SQL_Error里带一个明确的错误码。常见的就有1062主键重复、1032删除或修改时找不到记录、1452外键失败、1054字段不存在、1064语法异常、1213死锁、1205锁等待超时。每一种错误的含义不同对应的修复手段天差地别绝不可能一把梭。第三类线程都在跑但延迟逐渐拉大也就是Seconds_Behind_Master从0爬到几百、几千。这类不报错但对业务影响同样致命——从库数据落后太多读请求打到上面拿到的全是过期数据。延迟积压的根源通常是大事务、无索引字段的批量更新、DDL操作或者从库硬件配置比主库差一截。自动修复在这里能做的是监控与限流触发真正治本要靠慢查询优化和把大事务拆小。1.2 算一笔账一次凌晨事故的真实时间消耗我翻了去年一整年的处理记录做过一个小统计。手上二十多个从库实例全年由主从中断触发的告警有四十多次其中真正需要人工写SQL去处理的占了超过一半每次平均耗时在四十分钟左右。成本不只是那四十分钟还包括被预警打断的睡眠、值班人从床上爬起来到电脑前的时间、在处理过程中反复跟业务方确认操作影响的时间以及最让人心累的——处理完一个错误后START SLAVE跑几秒又报下一个错误你只好再来一轮。更隐性的一层成本是误操作风险。凌晨两点人本身不在清醒状态面对一个1062你很容易想“跳过吧反正就一条”结果跳过的那条事务可能是一个房产表的关键更新后果要在几个小时之后数据对账才发现。又比如1032类的“记录不存在”有人会直接STOP SLAVE然后在从库手动插入一条记录再继续复制但插入的数据跟主库当时binlog里的真正内容是否一致没人能打包票。手动处理主从报错这件事问题不在于“能不能做”而在于“每一次都靠人记忆和经验判断既慢又不稳定”。这跟我之前接手过的自动化发版一模一样的逻辑重复的、有固定规则的操作就应该让机器去做人只处理真正需要判断的事。这才是我做repl-healer的起点。2. 自动修复工具的三个设计原则不碰数据、能补则补、补不了就拉闸决定做自动修复之后我最怕的就是把工具做成一个“跳过一切错误”的败家子。如果只在代码里写一句STOP SLAVE; SET GLOBAL sql_slave_skip_counter1; START SLAVE那确实能消掉绝大多数报错但这等于把主从复制的一致性全毁了。在主库更新并写入binlog之后从库跳过这条事务两边数据就从那个点开始分叉——短期看不出来等到某天从库被提升为主库数据已经对不上了那才是真正的事故。所以我在设计之前先定了三条铁律这三条后面所有代码逻辑都是它们的展开。2.1 原则一修复动作只作用于复制链路绝不直接修改业务数据自动修复工具能做的是重启复制线程、跳过明确判定为无害的事务、重新建立主从关系但绝不应该自动在从库里插入、删除或修改业务表的数据。为什么这条要放在第一位因为很多报错如果真要彻底解决必然要动数据——比如1032报错在从库回放update或delete时找不到记录最彻底的修法是把主库那条数据同步过来但这条数据当前到底长什么样主库的binlog里有没有完整的before/after镜像从库是否允许被补数据这些都是必须走审批和场景判断的不是脚本看一眼就能拍板的事。我的做法是自动修复只处理“重放与跳过”层面的操作凡是需要动业务行的场景一律交给告警和人工工单。这个边界非常关键它决定了工具的权限模型和安全半径。2.2 原则二能补则补、不能补则跳过但跳过必须有前提“跳过”在很多人眼里是洪水猛兽但它其实是MySQL主从复制体系内置的一种恢复手段。问题在于跳过不能是“无差别跳过”必须基于明确的错误类型分类。我自己整理了一个错误处理矩阵后面细讲这里先举几个例子对于1205锁等待超时和1213死锁这类错误本质上是一条事务在从库重放时遇到了并发冲突事务本身没有问题下次重放大概率能过所以修复动作为“直接重启SQL线程”对于1062主键重复就需要进入更深层的判断这条报错是从库已经有同主键的数据而主库再次插入所致这种情况下如果直接跳过从库和主库在这条记录上只是“看起来一样”但如果两边数据内容不同后面任何一次更新都会出现新的分叉对于1032找不到记录跳过之后意味着从库缺少主库上存在的一次变更这往往会造成严重的不一致不能盲目跳所以“跳过”的前提取决于错误码的语义以及我们是否掌握了主从之间的一致状态。凡是判断不了的宁可报警也不动这是原则三。2.3 原则三修复动作必须有边界连续失败立刻熔断自动修复工具最大的风险是“自动”本身。想象一个场景脚本判断错误为1062执行跳过一个事务然后第二个事务还是1062再跳过一个第三个还是1062……如果没有任何限制脚本会在几分钟内跳过大量事务把主从直接搞成分裂状态。这比不修还可怕。因此我设置了两个熔断机制。一是单次故障修复次数上限同一个错误类型触发自动修复最多连续尝试3次3次之后不再自动修直接转人工告警。二是时间窗口抑制在一个小时内同一个实例若发生超过5次自主修复后续修复动作全部挂起。这两个数字不是拍脑袋出来的是我统计了故障分布之后定的正常瞬断类故障往往1次重启就恢复真正有数据问题的故障连续触发的概率极高3次足以暴露。熔断之后告警消息会带上前面几轮修复的完整记录值班人可以直接拿着这些日志去定位不用再从头翻mysql日志。3. 核心实现从错误识别、分类决策到修复动作的完整链路设计原则落地之后真正的重点是实现链路。我把它拆成了五个环节状态采集、错误分类、策略映射、动作执行、结果自检。这五个环节形成了一个闭环任何一个环节没有完成验证都不会进入下一步。3.1 状态采集定时任务解析SHOW SLAVE STATUS的关键细节自动修复的第一步不是修而是持续地、正确地采集主从状态。我用的是Python脚本通过系统计划任务每30秒执行一次检查但这其实有讲究——你不可能每次检查都厚着脸皮去SHOW SLAVE STATUS尤其是实例数量多的时候很容易把从库本身压垮也容易在数据库账号审计里留下海量查询记录。我最终采用的方案是一个常驻的巡检进程每30秒跑一次轻量查询。采集的核心字段包括Slave_IO_Running和Slave_SQL_Running两个状态位这是最基础的入口Last_IO_Error/Last_SQL_Error以及对应的时间戳这是判断问题根因的主要依据Seconds_Behind_Master延迟值用于延迟积压的判断Retrieved_Gtid_Set和Executed_Gtid_Set用于对比主从GTID集合之间的差异Master_Log_File/Read_Master_Log_Pos/Relay_Master_Log_File/Exec_Master_Log_Pos这组位置信息在非GTID模式下至关重要可以精确定位从库当前重放的binlog坐标这里有个极大的坑很多运维脚本用正则去解析SHOW SLAVE STATUS的纯文本输出然后在字段索引变化时彻底跑飞。MySQL在部分版本里会追加新字段解析代码如果按硬编码位置取值轻则拿到空的延迟值重则把IO线程和SQL线程的状态位搞反从而做出完全错误的修复判断。我的做法是先把输出转成字典用字段名精准取值并且兼容SHOW SLAVE STATUS与SHOW REPLICA STATUS两种语法因为MySQL 8.0.22之后SHOW REPLICA STATUS才是官方推荐命令前者被标记为废弃。3.2 错误分类器如何区分哪些错误能自动修哪些必须拉响告警分类是整个工具的核心判断环节。我把最常见的错误码整理成了策略映射表并根据实际线上表现持续调整。这是一开始最重要的工作没有这套分类矩阵后续的一切都无从谈起。错误码错误含义自动修复策略修复动作1205锁等待超时可安全重试直接START SLAVE1213事务死锁可安全重试直接START SLAVE1062主键重复需进一步判断后决定检查重复行内容一致则跳过不一致转人工1032找不到匹配记录默认不自动修转人工分析主库binlog1452外键约束失败默认不自动修转人工评估父表数据1054字段不存在不自动修大概率表结构不一致转人工1045访问被拒绝不自动修账号权限问题转人工1064语法错误不自动修检查事件SQL语义转人工1236主库binlog读取失败可尝试重新定位根据GTID重新change master1594relay log损坏可尝试重建relay log重设复制链路这张表不是静态的我每季度会拿线上故障记录回来复盘看哪些自动修的决策后来又引发了新的不一致。比如1062我第一次设计时认为如果是主键重复大概率是从库此前已经存在同一条数据可能只是某个环节重复应用跳过是安全的。但后来在一次金融类业务的对账中发现主从两边虽然主键一样字段值却不一致——从库的存在一条旧版本主库的新版本插入被从库误判为重复。那之后再遇到1062我默认的流程就改变为先挑选出重复主键对应的记录对比从库与主库的字段快照只有完全一致时才允许跳过否则转为人工。3.3 动作执行从sql_slave_skip_counter到GTID空事务的取舍执行层是真正操作MySQL的地方。我实现了几类修复动作每类的细节都是在线上反复试错之后定下来的。第一个动作是纯重启SQL线程针对的是1205和1213这类瞬时冲突。SQL很简单STOP SLAVE SQL_THREAD; START SLAVE SQL_THREAD;代码里调用.execute()前注意加超时控制我踩过连接池假死的坑后来统一用SET SESSION MAX_EXECUTION_TIME或者干脆在连接层面加connect_timeout和read_timeout。第二个动作是针对单条事务的跳过。这里我要特别强调一个MySQL的版本差异在传统位点复制模式下SET GLOBAL sql_slave_skip_counter1确实可以跳过下一条事务但在开启GTID模式后这个全局变量虽然还存在但官方并不推荐使用而且在某些交叉组合下会出现跳过无效或跳错事务的情况。更稳的GTID模式跳过方式是“注入空事务”STOP SLAVE; SET GTID_NEXTuuid:事务序号; BEGIN; COMMIT; SET GTID_NEXTAUTOMATIC; START SLAVE;这个操作的本质是告诉从库“这个GTID的事务我已经执行过了”然后继续往下走。因为从库执行到该位置时发现没有对应的事务数据但它认为已经消费掉于是跳过。这要求你知道错误点对应的确切GTID序号。好在现在从库的Last_SQL_Error和SHOW SLAVE STATUS里的Retrieved_Gtid_Set往往能直接带出线索再加上performance_schema.replication_applier_status_by_worker里的LAST_APPLIED_TRANSACTION可以拿到具体事务实操起来比传统位点模式要精准不少。第三个动作比较复杂用于IO线程掉线后重建复制链路。很多人试过STOP SLAVE; START SLAVE重连但遇到1236这类错误时根本没用因为从库记录的位置在主库上已经找不到对应的binlog文件了。这时需要重新指定位点。GTID模式下的标准做法是STOP SLAVE; CHANGE MASTER TO MASTER_AUTO_POSITION1; START SLAVE;如果是非GTID模式就需要先从主库查当前binlog位点然后精准指定CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000213, MASTER_LOG_POS108473580;执行这步操作前一定要先确认从库的relay log已经全部重放完毕。最稳妥的方式是STOP SLAVE后等待Relay_Log_File和Relay_Log_Pos不再变化再检查RETRIEVED_GTID_SET和EXECUTED_GTID_SET一致。否则贸然重建链路可能丢掉一批尚未重放的事务这不是修复是二次破坏。3.4 修复后的自检闭环光把线程拉起来不算完修复动作执行完后很多人觉得START SLAVE成功看到RunningYes就收工了其实这才完成了一半。我在工具里强制要求跑完一组自检第一步等一个采集周期30秒之后确认Slave_IO_Running和Slave_SQL_Running都保持Yes第二步确认Last_IO_Error和Last_SQL_Error的值为空且错误时间戳不再更新第三步连续三次采集Seconds_Behind_Master确认延迟在逐步下降而不是继续扩大第四步对于做过跳过的场景额外执行一次主从两端关键表的行数对比抽样校验确认没有因为跳过造成明显的数据缺失这四步都过了工具才会在告警群里标记为“自动修复成功”。任何一个环节没通过都会触发新一轮的判断逻辑如果已达重试上限就升级为人工工单。我在自检环节踩过一个特别想分享的坑只盯着Seconds_Behind_Master看容易造成误判。有一次主从两端在大表上执行不同的DDL从库的延迟从几秒直接飙到几万秒但Slave_IO_Running和Slave_SQL_Running都是Yes于是工具把它归为“延迟积压”触发了一个“重连”动作结果STOP SLAVE时因为长事务回放未完成卡了整整二十分钟。后来我调整了阈值只有当Seconds_Behind_Master同时满足“持续三次采集递增”和“单次增量超过60秒”时才认为需要干预否则只记录观察不动作。4. 防呆与容错再智能的修复也要给自己设一道保险自动修复工具本质上也是一段会出故障的代码。如果我写的巡检进程自己挂了或者误读了状态然后一堆错误的修复指令发到从库上那这个工具的破坏力比值班人犯一次错还大。因此我在设计阶段就把“工具自身的故障半径”压到了最小。4.1 权限模型只给从库一个最小权限账号工具使用的MySQL账号权限被控制在极小范围。我需要执行SHOW SLAVE STATUS、START SLAVE、STOP SLAVE、CHANGE MASTER但绝不需要它去读写业务表。账号最终授权是这样的GRANT REPLICATION SLAVE, BACKUP_ADMIN ON *.* TO healer127.0.0.1; GRANT SELECT ON performance_schema.* TO healer127.0.0.1;REPLICATION SLAVE权限足以执行复制管理类的命令BACKUP_ADMIN是因为新版MySQL里部分复制状态查询需要它。业务库一个都不授权这样就算工具被攻破或者我代码里手滑写了一个DELETE由于权限限制也会直接报错不会伤害数据。这比把一堆高级权限塞给工具账号再指望自己小心要靠谱得多。4.2 熔断机制与告警去重宁可少修不可乱修前面提到过熔断上限这里补充一个细节熔断不能只计数还要有“冷却时间”。我的实现里每一次自动修复都会写入本地状态文件包含实例名、时间、错误码、成功与否。连续3次失败后进入冷却期冷却期内任何自动修复都不会被触发直到值班人手动确认并重置状态。这样可以避免一种很尴尬的情况故障从凌晨2点持续到早上8点工具每30秒尝试一次每一轮都失败相当于每隔一小会儿就往告警群扔一条失败消息把值班人和告警接收通道一起打崩溃。告警去重和聚合也是我强烈建议做的。同一时刻多个从库一起报错往往不是各修各的而是有一个共性根因比如主库做了重启或者网络交换机抖动。工具把所有失败事件聚合成一张摘要表按实例、错误码、发生时间段分组聚合消息只在第一次发生和状态变更时推送。4.3 工具自身的守护如果巡检进程挂了谁来发现问题我见过很多自动化的系统自动化进程自己先倒下然后一切回到靠人肉盯屏的老路。repl-healer的巡检进程本身我用了一个极简单的外部守护脚本每年检查一次进程是否存在不存在就向告警通道发一条HEALER_DOWN消息同时把自动修复入口关闭。这样做的逻辑是当自动修复系统本身不可用的时候我们宁可让主从报错直接暴露给人工也不能让一个半死的进程在状态下不全的情况下瞎跳。状态文件里每次执行前都写开始时间执行完写结束时间如果发现上一次执行没有结束时间就认为进程可能卡死同样会触发自愈重启。5. 部署一年之后实测数据、踩坑清单与我的最终体会从2022年12月到2024年初这套工具在我负责的MySQL实例上跑了超过一年累计自动处理主从异常一百多次人工接手率压到了差不多两成。而且值得说明的是人工接手的那两成里有一半是因为连续失败触发了熔断最后检查下来确实需要真刀真枪地去调整表结构或主从链路属于工具正确地把该交给人的事踢给了人。5.1 一年故障数据分布什么样的故障自动修得最多我拉了一下工具自带的审计表把故障类型做了个汇总比较能说明自动修复的真实面貌故障类型次数自动修复成功率典型原因SQL线程瞬时锁冲突1205/121342100%从库并发写入造成短暂锁竞争IO线程网络闪断重连3594%机房网络抖动、主库连接数峰值SQL线程1062主键重复1973%重复执行幂等插入场景SQL线程1032记录丢失120%全部转人工主从数据不一致、手工在从库改过数据relay log 损坏862%磁盘满、kill -9、系统崩溃70多次的成功自动修复意味着什么按照我之前预估的每次40分钟人工耗时大约省出了四十多个小时的夜间值班时间。而这还只是直接节省的时间间接上避免的误操作、缓解的焦虑情绪才是更大的收益。不过我必须强调所有成功自动跳过的场景事后我都强制跑过一轮全库数据校验用pt-table-checksum按表对比主从。这个动作是底线不可省。自动修复只是让复制链路重新跑起来至于链路上已经存在的偏差只能靠校验去发现靠人去兜底。5.2 复盘几个让我印象深刻的坑第一个坑高估了binlog中镜像数据的完整性。设计1032的自动补齐方案时我原本打算从主库的binlog里提取执行前的数据在从库补一条历史记录再继续复制。实测却发现很多线上表的binlog_row_image是MINIMALbinlog里只记录了被修改的列、不记录完整的前镜像。你根本拿不到“当时的完整记录”自然没法安全地补数据进从库。这个坑让我彻底放弃了尝试最终决定1032类错误全部转人工宁可慢不可错。第二个坑1062类型的处理必须依赖主从数据对比而不是看报错本身。我最初按“直接判断能否跳过”来设计后来在一次回访中发现从库的疑似重复行跟主库最新的数据有很大出入原因是从库之前被某个人手工改过。从那以后1062跳过前强制加了一道校验用SELECT取出主从两边对应行的所有字段逐字段对比一致才放行。第三个坑自动修复的日志也要能被人看懂。早期版本的审计日志只是简单记录“已跳过事务xxx”三个月后回看根本不知道当时为什么跳、跳过的事务属于哪个业务表、背后关联的GTID范围是什么。后来我重写了审计结构每一条记录都包含错误原文、错误码、修复动作类型、修复耗时、涉及的GTID集合、修复跳过的具体事务ID、后续校验结论。这个日志在告警复盘、数据差异定位时价值极其巨大。5.3 一点最终建议先半自动验证再全自动放手如果有人想在自己的环境里做这件事我最真诚的建议是第一版只做诊断和告警不做修复动作。先把自动分类逻辑跑上一两个月让它输出“如果当时是我我会执行A、B还是C”然后拿这些判断跟人工实际处理结果去做对比不断校准确认两边判断一致率达到九成以上再打开自动修复开关。不要一上来就全自动尤其是别在核心生产库上一上来就全自动。我当时是先在一个灰度业务从库上跑了两个月每一条自动修复指令都推送到群里请另一个值班人复核确认不会误判之后才逐步扩大到所有从库。这几个月里工具帮我重新梳理了一遍所有从库的主从配置还发现了两个长期潜伏的隐患一个从库的MASTER_AUTO_POSITION之前被错误地设置成了0一个从库的复制账号密码已经过期但大家都不知道。敢于让工具在前面探路是因为每一步都有闸门每一轮结果都有审计就算它判断错了也有足够的手段把人拉回现场。最后分享一个我很坚持的小习惯不管自动修复跑得多稳我仍然每月手动抽查一次主从数据一致性并在每次版本升级后重新做一次全量校验。工具负责的是日常的“止血”和“快速恢复”而数据一致性这件事永远值得你亲自盯一眼。
MySQL主从复制故障自动修复：设计思路与实战经验
1. 凌晨三点的主从中断手动处理的成本到底有多高我先说一个真实场景。凌晨两点五十七分手机震了告警平台上一条P2消息某业务从库的Slave_SQL_Running变成No。你爬起来打开电脑登录从库敲一句SHOW SLAVE STATUS\G看到Last_SQL_Error是Error Duplicate entry 10086 for key PRIMARY on query也就是1062主键冲突。常规操作就来了分析这条报错评估能不能跳过确认跳过之后会不会造成数据不一致然后STOP SLAVE、SET GLOBAL sql_slave_skip_counter1、START SLAVE再观察Seconds_Behind_Master能不能追到0。运气好十几分钟收工运气不好跳过之后又报下一条你整个人就麻了。这就是MySQL主从运维里最常见的夜班噩梦。主从复制本质上是一个不断从主库拉取binlog、写入relay log、再在从库回放的过程任何一个环节出问题复制线程就会停下而它不会自己恢复。传统做法是人工介入看错误、判断影响、执行修复。问题在于故障类型翻来覆去就那么几类处理手法高度重复但因为每一条错误背后可能藏着不一致的隐患没人敢直接写个脚本粗暴地sql_slave_skip_counter1一路跳过去。但也正因为如此这件事可以做得比大部分人想象中更自动、更安全。我花了大半年时间把一个手动处理主从报错的流程逐步重构成了一个带诊断、分类、修复、自检、熔断的自动化工具内部代号叫repl-healer。这篇文章把我整个设计思路和踩坑经历写出来适合正在被MySQL主从报错折磨的运维同学、刚接手从库管理的DBA以及那些想给自己手头一坨实例找条出路的兼职运维。不说大而全的治理方案只说一件事主从报错到底能不能自动修怎么修才不会把数据修出更大的坑。1.1 主从中断最常见的三类故障IO线程、SQL线程与延迟积压要谈自动修复先得把故障分清楚。SHOW SLAVE STATUS里面有两根关键的线程状态Slave_IO_Running和Slave_SQL_Running。我见过不少刚入行的同事只看这两个字段是不是Yes但其实故障至少分三类。第一类IO线程断连。表象是Slave_IO_Running: Connecting或者NoLast_IO_Error往往指向网络超时、主库连接数打满、主库重启、甚至主从之间binlog位置失效。这类故障通常不影响从库上的既有数据修复动作相对安全以重连、重新拉取binlog为主。我遇到过的典型错误是Got fatal error 1236 from master when reading data from binary log: Could not find first log file name in binary log index第一次碰上那真是冷汗直冒后面才知道这大多是从库的relay log被清理、主库binlog被purge或者change master时指定的MASTER_LOG_FILE已经不存在了。第二类SQL线程报错这是最麻烦的一类。表现为Slave_SQL_Running: NoLast_SQL_Error里带一个明确的错误码。常见的就有1062主键重复、1032删除或修改时找不到记录、1452外键失败、1054字段不存在、1064语法异常、1213死锁、1205锁等待超时。每一种错误的含义不同对应的修复手段天差地别绝不可能一把梭。第三类线程都在跑但延迟逐渐拉大也就是Seconds_Behind_Master从0爬到几百、几千。这类不报错但对业务影响同样致命——从库数据落后太多读请求打到上面拿到的全是过期数据。延迟积压的根源通常是大事务、无索引字段的批量更新、DDL操作或者从库硬件配置比主库差一截。自动修复在这里能做的是监控与限流触发真正治本要靠慢查询优化和把大事务拆小。1.2 算一笔账一次凌晨事故的真实时间消耗我翻了去年一整年的处理记录做过一个小统计。手上二十多个从库实例全年由主从中断触发的告警有四十多次其中真正需要人工写SQL去处理的占了超过一半每次平均耗时在四十分钟左右。成本不只是那四十分钟还包括被预警打断的睡眠、值班人从床上爬起来到电脑前的时间、在处理过程中反复跟业务方确认操作影响的时间以及最让人心累的——处理完一个错误后START SLAVE跑几秒又报下一个错误你只好再来一轮。更隐性的一层成本是误操作风险。凌晨两点人本身不在清醒状态面对一个1062你很容易想“跳过吧反正就一条”结果跳过的那条事务可能是一个房产表的关键更新后果要在几个小时之后数据对账才发现。又比如1032类的“记录不存在”有人会直接STOP SLAVE然后在从库手动插入一条记录再继续复制但插入的数据跟主库当时binlog里的真正内容是否一致没人能打包票。手动处理主从报错这件事问题不在于“能不能做”而在于“每一次都靠人记忆和经验判断既慢又不稳定”。这跟我之前接手过的自动化发版一模一样的逻辑重复的、有固定规则的操作就应该让机器去做人只处理真正需要判断的事。这才是我做repl-healer的起点。2. 自动修复工具的三个设计原则不碰数据、能补则补、补不了就拉闸决定做自动修复之后我最怕的就是把工具做成一个“跳过一切错误”的败家子。如果只在代码里写一句STOP SLAVE; SET GLOBAL sql_slave_skip_counter1; START SLAVE那确实能消掉绝大多数报错但这等于把主从复制的一致性全毁了。在主库更新并写入binlog之后从库跳过这条事务两边数据就从那个点开始分叉——短期看不出来等到某天从库被提升为主库数据已经对不上了那才是真正的事故。所以我在设计之前先定了三条铁律这三条后面所有代码逻辑都是它们的展开。2.1 原则一修复动作只作用于复制链路绝不直接修改业务数据自动修复工具能做的是重启复制线程、跳过明确判定为无害的事务、重新建立主从关系但绝不应该自动在从库里插入、删除或修改业务表的数据。为什么这条要放在第一位因为很多报错如果真要彻底解决必然要动数据——比如1032报错在从库回放update或delete时找不到记录最彻底的修法是把主库那条数据同步过来但这条数据当前到底长什么样主库的binlog里有没有完整的before/after镜像从库是否允许被补数据这些都是必须走审批和场景判断的不是脚本看一眼就能拍板的事。我的做法是自动修复只处理“重放与跳过”层面的操作凡是需要动业务行的场景一律交给告警和人工工单。这个边界非常关键它决定了工具的权限模型和安全半径。2.2 原则二能补则补、不能补则跳过但跳过必须有前提“跳过”在很多人眼里是洪水猛兽但它其实是MySQL主从复制体系内置的一种恢复手段。问题在于跳过不能是“无差别跳过”必须基于明确的错误类型分类。我自己整理了一个错误处理矩阵后面细讲这里先举几个例子对于1205锁等待超时和1213死锁这类错误本质上是一条事务在从库重放时遇到了并发冲突事务本身没有问题下次重放大概率能过所以修复动作为“直接重启SQL线程”对于1062主键重复就需要进入更深层的判断这条报错是从库已经有同主键的数据而主库再次插入所致这种情况下如果直接跳过从库和主库在这条记录上只是“看起来一样”但如果两边数据内容不同后面任何一次更新都会出现新的分叉对于1032找不到记录跳过之后意味着从库缺少主库上存在的一次变更这往往会造成严重的不一致不能盲目跳所以“跳过”的前提取决于错误码的语义以及我们是否掌握了主从之间的一致状态。凡是判断不了的宁可报警也不动这是原则三。2.3 原则三修复动作必须有边界连续失败立刻熔断自动修复工具最大的风险是“自动”本身。想象一个场景脚本判断错误为1062执行跳过一个事务然后第二个事务还是1062再跳过一个第三个还是1062……如果没有任何限制脚本会在几分钟内跳过大量事务把主从直接搞成分裂状态。这比不修还可怕。因此我设置了两个熔断机制。一是单次故障修复次数上限同一个错误类型触发自动修复最多连续尝试3次3次之后不再自动修直接转人工告警。二是时间窗口抑制在一个小时内同一个实例若发生超过5次自主修复后续修复动作全部挂起。这两个数字不是拍脑袋出来的是我统计了故障分布之后定的正常瞬断类故障往往1次重启就恢复真正有数据问题的故障连续触发的概率极高3次足以暴露。熔断之后告警消息会带上前面几轮修复的完整记录值班人可以直接拿着这些日志去定位不用再从头翻mysql日志。3. 核心实现从错误识别、分类决策到修复动作的完整链路设计原则落地之后真正的重点是实现链路。我把它拆成了五个环节状态采集、错误分类、策略映射、动作执行、结果自检。这五个环节形成了一个闭环任何一个环节没有完成验证都不会进入下一步。3.1 状态采集定时任务解析SHOW SLAVE STATUS的关键细节自动修复的第一步不是修而是持续地、正确地采集主从状态。我用的是Python脚本通过系统计划任务每30秒执行一次检查但这其实有讲究——你不可能每次检查都厚着脸皮去SHOW SLAVE STATUS尤其是实例数量多的时候很容易把从库本身压垮也容易在数据库账号审计里留下海量查询记录。我最终采用的方案是一个常驻的巡检进程每30秒跑一次轻量查询。采集的核心字段包括Slave_IO_Running和Slave_SQL_Running两个状态位这是最基础的入口Last_IO_Error/Last_SQL_Error以及对应的时间戳这是判断问题根因的主要依据Seconds_Behind_Master延迟值用于延迟积压的判断Retrieved_Gtid_Set和Executed_Gtid_Set用于对比主从GTID集合之间的差异Master_Log_File/Read_Master_Log_Pos/Relay_Master_Log_File/Exec_Master_Log_Pos这组位置信息在非GTID模式下至关重要可以精确定位从库当前重放的binlog坐标这里有个极大的坑很多运维脚本用正则去解析SHOW SLAVE STATUS的纯文本输出然后在字段索引变化时彻底跑飞。MySQL在部分版本里会追加新字段解析代码如果按硬编码位置取值轻则拿到空的延迟值重则把IO线程和SQL线程的状态位搞反从而做出完全错误的修复判断。我的做法是先把输出转成字典用字段名精准取值并且兼容SHOW SLAVE STATUS与SHOW REPLICA STATUS两种语法因为MySQL 8.0.22之后SHOW REPLICA STATUS才是官方推荐命令前者被标记为废弃。3.2 错误分类器如何区分哪些错误能自动修哪些必须拉响告警分类是整个工具的核心判断环节。我把最常见的错误码整理成了策略映射表并根据实际线上表现持续调整。这是一开始最重要的工作没有这套分类矩阵后续的一切都无从谈起。错误码错误含义自动修复策略修复动作1205锁等待超时可安全重试直接START SLAVE1213事务死锁可安全重试直接START SLAVE1062主键重复需进一步判断后决定检查重复行内容一致则跳过不一致转人工1032找不到匹配记录默认不自动修转人工分析主库binlog1452外键约束失败默认不自动修转人工评估父表数据1054字段不存在不自动修大概率表结构不一致转人工1045访问被拒绝不自动修账号权限问题转人工1064语法错误不自动修检查事件SQL语义转人工1236主库binlog读取失败可尝试重新定位根据GTID重新change master1594relay log损坏可尝试重建relay log重设复制链路这张表不是静态的我每季度会拿线上故障记录回来复盘看哪些自动修的决策后来又引发了新的不一致。比如1062我第一次设计时认为如果是主键重复大概率是从库此前已经存在同一条数据可能只是某个环节重复应用跳过是安全的。但后来在一次金融类业务的对账中发现主从两边虽然主键一样字段值却不一致——从库的存在一条旧版本主库的新版本插入被从库误判为重复。那之后再遇到1062我默认的流程就改变为先挑选出重复主键对应的记录对比从库与主库的字段快照只有完全一致时才允许跳过否则转为人工。3.3 动作执行从sql_slave_skip_counter到GTID空事务的取舍执行层是真正操作MySQL的地方。我实现了几类修复动作每类的细节都是在线上反复试错之后定下来的。第一个动作是纯重启SQL线程针对的是1205和1213这类瞬时冲突。SQL很简单STOP SLAVE SQL_THREAD; START SLAVE SQL_THREAD;代码里调用.execute()前注意加超时控制我踩过连接池假死的坑后来统一用SET SESSION MAX_EXECUTION_TIME或者干脆在连接层面加connect_timeout和read_timeout。第二个动作是针对单条事务的跳过。这里我要特别强调一个MySQL的版本差异在传统位点复制模式下SET GLOBAL sql_slave_skip_counter1确实可以跳过下一条事务但在开启GTID模式后这个全局变量虽然还存在但官方并不推荐使用而且在某些交叉组合下会出现跳过无效或跳错事务的情况。更稳的GTID模式跳过方式是“注入空事务”STOP SLAVE; SET GTID_NEXTuuid:事务序号; BEGIN; COMMIT; SET GTID_NEXTAUTOMATIC; START SLAVE;这个操作的本质是告诉从库“这个GTID的事务我已经执行过了”然后继续往下走。因为从库执行到该位置时发现没有对应的事务数据但它认为已经消费掉于是跳过。这要求你知道错误点对应的确切GTID序号。好在现在从库的Last_SQL_Error和SHOW SLAVE STATUS里的Retrieved_Gtid_Set往往能直接带出线索再加上performance_schema.replication_applier_status_by_worker里的LAST_APPLIED_TRANSACTION可以拿到具体事务实操起来比传统位点模式要精准不少。第三个动作比较复杂用于IO线程掉线后重建复制链路。很多人试过STOP SLAVE; START SLAVE重连但遇到1236这类错误时根本没用因为从库记录的位置在主库上已经找不到对应的binlog文件了。这时需要重新指定位点。GTID模式下的标准做法是STOP SLAVE; CHANGE MASTER TO MASTER_AUTO_POSITION1; START SLAVE;如果是非GTID模式就需要先从主库查当前binlog位点然后精准指定CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000213, MASTER_LOG_POS108473580;执行这步操作前一定要先确认从库的relay log已经全部重放完毕。最稳妥的方式是STOP SLAVE后等待Relay_Log_File和Relay_Log_Pos不再变化再检查RETRIEVED_GTID_SET和EXECUTED_GTID_SET一致。否则贸然重建链路可能丢掉一批尚未重放的事务这不是修复是二次破坏。3.4 修复后的自检闭环光把线程拉起来不算完修复动作执行完后很多人觉得START SLAVE成功看到RunningYes就收工了其实这才完成了一半。我在工具里强制要求跑完一组自检第一步等一个采集周期30秒之后确认Slave_IO_Running和Slave_SQL_Running都保持Yes第二步确认Last_IO_Error和Last_SQL_Error的值为空且错误时间戳不再更新第三步连续三次采集Seconds_Behind_Master确认延迟在逐步下降而不是继续扩大第四步对于做过跳过的场景额外执行一次主从两端关键表的行数对比抽样校验确认没有因为跳过造成明显的数据缺失这四步都过了工具才会在告警群里标记为“自动修复成功”。任何一个环节没通过都会触发新一轮的判断逻辑如果已达重试上限就升级为人工工单。我在自检环节踩过一个特别想分享的坑只盯着Seconds_Behind_Master看容易造成误判。有一次主从两端在大表上执行不同的DDL从库的延迟从几秒直接飙到几万秒但Slave_IO_Running和Slave_SQL_Running都是Yes于是工具把它归为“延迟积压”触发了一个“重连”动作结果STOP SLAVE时因为长事务回放未完成卡了整整二十分钟。后来我调整了阈值只有当Seconds_Behind_Master同时满足“持续三次采集递增”和“单次增量超过60秒”时才认为需要干预否则只记录观察不动作。4. 防呆与容错再智能的修复也要给自己设一道保险自动修复工具本质上也是一段会出故障的代码。如果我写的巡检进程自己挂了或者误读了状态然后一堆错误的修复指令发到从库上那这个工具的破坏力比值班人犯一次错还大。因此我在设计阶段就把“工具自身的故障半径”压到了最小。4.1 权限模型只给从库一个最小权限账号工具使用的MySQL账号权限被控制在极小范围。我需要执行SHOW SLAVE STATUS、START SLAVE、STOP SLAVE、CHANGE MASTER但绝不需要它去读写业务表。账号最终授权是这样的GRANT REPLICATION SLAVE, BACKUP_ADMIN ON *.* TO healer127.0.0.1; GRANT SELECT ON performance_schema.* TO healer127.0.0.1;REPLICATION SLAVE权限足以执行复制管理类的命令BACKUP_ADMIN是因为新版MySQL里部分复制状态查询需要它。业务库一个都不授权这样就算工具被攻破或者我代码里手滑写了一个DELETE由于权限限制也会直接报错不会伤害数据。这比把一堆高级权限塞给工具账号再指望自己小心要靠谱得多。4.2 熔断机制与告警去重宁可少修不可乱修前面提到过熔断上限这里补充一个细节熔断不能只计数还要有“冷却时间”。我的实现里每一次自动修复都会写入本地状态文件包含实例名、时间、错误码、成功与否。连续3次失败后进入冷却期冷却期内任何自动修复都不会被触发直到值班人手动确认并重置状态。这样可以避免一种很尴尬的情况故障从凌晨2点持续到早上8点工具每30秒尝试一次每一轮都失败相当于每隔一小会儿就往告警群扔一条失败消息把值班人和告警接收通道一起打崩溃。告警去重和聚合也是我强烈建议做的。同一时刻多个从库一起报错往往不是各修各的而是有一个共性根因比如主库做了重启或者网络交换机抖动。工具把所有失败事件聚合成一张摘要表按实例、错误码、发生时间段分组聚合消息只在第一次发生和状态变更时推送。4.3 工具自身的守护如果巡检进程挂了谁来发现问题我见过很多自动化的系统自动化进程自己先倒下然后一切回到靠人肉盯屏的老路。repl-healer的巡检进程本身我用了一个极简单的外部守护脚本每年检查一次进程是否存在不存在就向告警通道发一条HEALER_DOWN消息同时把自动修复入口关闭。这样做的逻辑是当自动修复系统本身不可用的时候我们宁可让主从报错直接暴露给人工也不能让一个半死的进程在状态下不全的情况下瞎跳。状态文件里每次执行前都写开始时间执行完写结束时间如果发现上一次执行没有结束时间就认为进程可能卡死同样会触发自愈重启。5. 部署一年之后实测数据、踩坑清单与我的最终体会从2022年12月到2024年初这套工具在我负责的MySQL实例上跑了超过一年累计自动处理主从异常一百多次人工接手率压到了差不多两成。而且值得说明的是人工接手的那两成里有一半是因为连续失败触发了熔断最后检查下来确实需要真刀真枪地去调整表结构或主从链路属于工具正确地把该交给人的事踢给了人。5.1 一年故障数据分布什么样的故障自动修得最多我拉了一下工具自带的审计表把故障类型做了个汇总比较能说明自动修复的真实面貌故障类型次数自动修复成功率典型原因SQL线程瞬时锁冲突1205/121342100%从库并发写入造成短暂锁竞争IO线程网络闪断重连3594%机房网络抖动、主库连接数峰值SQL线程1062主键重复1973%重复执行幂等插入场景SQL线程1032记录丢失120%全部转人工主从数据不一致、手工在从库改过数据relay log 损坏862%磁盘满、kill -9、系统崩溃70多次的成功自动修复意味着什么按照我之前预估的每次40分钟人工耗时大约省出了四十多个小时的夜间值班时间。而这还只是直接节省的时间间接上避免的误操作、缓解的焦虑情绪才是更大的收益。不过我必须强调所有成功自动跳过的场景事后我都强制跑过一轮全库数据校验用pt-table-checksum按表对比主从。这个动作是底线不可省。自动修复只是让复制链路重新跑起来至于链路上已经存在的偏差只能靠校验去发现靠人去兜底。5.2 复盘几个让我印象深刻的坑第一个坑高估了binlog中镜像数据的完整性。设计1032的自动补齐方案时我原本打算从主库的binlog里提取执行前的数据在从库补一条历史记录再继续复制。实测却发现很多线上表的binlog_row_image是MINIMALbinlog里只记录了被修改的列、不记录完整的前镜像。你根本拿不到“当时的完整记录”自然没法安全地补数据进从库。这个坑让我彻底放弃了尝试最终决定1032类错误全部转人工宁可慢不可错。第二个坑1062类型的处理必须依赖主从数据对比而不是看报错本身。我最初按“直接判断能否跳过”来设计后来在一次回访中发现从库的疑似重复行跟主库最新的数据有很大出入原因是从库之前被某个人手工改过。从那以后1062跳过前强制加了一道校验用SELECT取出主从两边对应行的所有字段逐字段对比一致才放行。第三个坑自动修复的日志也要能被人看懂。早期版本的审计日志只是简单记录“已跳过事务xxx”三个月后回看根本不知道当时为什么跳、跳过的事务属于哪个业务表、背后关联的GTID范围是什么。后来我重写了审计结构每一条记录都包含错误原文、错误码、修复动作类型、修复耗时、涉及的GTID集合、修复跳过的具体事务ID、后续校验结论。这个日志在告警复盘、数据差异定位时价值极其巨大。5.3 一点最终建议先半自动验证再全自动放手如果有人想在自己的环境里做这件事我最真诚的建议是第一版只做诊断和告警不做修复动作。先把自动分类逻辑跑上一两个月让它输出“如果当时是我我会执行A、B还是C”然后拿这些判断跟人工实际处理结果去做对比不断校准确认两边判断一致率达到九成以上再打开自动修复开关。不要一上来就全自动尤其是别在核心生产库上一上来就全自动。我当时是先在一个灰度业务从库上跑了两个月每一条自动修复指令都推送到群里请另一个值班人复核确认不会误判之后才逐步扩大到所有从库。这几个月里工具帮我重新梳理了一遍所有从库的主从配置还发现了两个长期潜伏的隐患一个从库的MASTER_AUTO_POSITION之前被错误地设置成了0一个从库的复制账号密码已经过期但大家都不知道。敢于让工具在前面探路是因为每一步都有闸门每一轮结果都有审计就算它判断错了也有足够的手段把人拉回现场。最后分享一个我很坚持的小习惯不管自动修复跑得多稳我仍然每月手动抽查一次主从数据一致性并在每次版本升级后重新做一次全量校验。工具负责的是日常的“止血”和“快速恢复”而数据一致性这件事永远值得你亲自盯一眼。
