MySQL运维设计实战：36小时崩盘到高可用蜕变

　　去年十一月，我蹲在三号机房角落啃冷掉的韭菜盒子，油渍糊在工牌上，刚好盖住“高级DBA”那行字。窗外雨下得没脾气，像服务器告警灯一样绵长无力——就是那天，凌晨三点十七分，主库挂了，从库跟丢，GTID跳变，binlog被删了十八秒，但没人敢说谁删的。我说完这句就后悔：其实我不确定是不是十八秒，也可能是十七或者十九，这个我说不准。

文章配图，仅供参考

　　优胜劣汰？对。不是玄学，是物理事实。那个自动切换脚本跑起来的前两秒，我手抖把ssh终端窗口关错了，连上了测试环境的proxySQL，然后眼睁睁看着它把一百四十个读请求全转发给了刚重启失败的只读实例。那台机器当时CPU 97%，load avg 是 42.6，风扇声像电锯切钢板。我听见小陈在隔壁喊“谁动了路由表”，但没人应。他喊完低头扒拉手机外卖，点的是麻辣香锅，红油汤底照片拍得跟InnoDB buffer pool脏页占比图一模一样。

　　真正把人钉死在椅子上的不是failover失败，是failback不敢做。我们在备库上手工补了三百七十二条事务，一条条校验XA状态、查undolog残留、比对undo_log表里的xid字段。小王蹲在物理机旁边，用万用表测磁盘背板电压，测完抬头说“稳”，但话音还没落，SSD缓存灯又灭了一颗。他说“稳”那会儿，我看见他指甲缝里还嵌着上周换RAID卡时沾的硅脂，灰绿色的，抹不净。这个我敢打包票。

　　你问我怎么熬过三十六小时？靠泡面汤底里的钠离子续命。第三包泡面煮完，汤还没喝，机柜顶上一块隔热棉突然脱落，“啪”一声砸在UPS蜂鸣器上，声音像极了mysqld崩溃时的core dump日志头三行。我愣了两秒才伸手去捡，结果发现棉里裹着半截没抽完的烟——不是我的，是前年离职的老刘留下的，打火机还卡在棉絮褶皱里，没生锈。我顺手揣兜里了，到现在还在。

　　高可用？呵。我们最后上线的新架构，核心就两条：一个是把semi-sync超时从1000毫秒砍到380，另一个是让所有DDL进队列，队列背后挂个能暂停的消费者。听起来朴素吧？可去年双十一零点前，消费队列真停了四分钟——因为运维同事在K8s里改了一个ConfigMap，把max-retries写成字符串“无限”而不是数字-1。Pod崩了三次才报错，第四次启动时终于解析成功。这事后来没人提，日志删干净了，只有监控截图留了个影子，我看的时候放大到120%，才发现时间轴上有个278毫秒的gap，刚好卡在那个ConfigMap reload和first pod ready之间。这种事，你信不信？反正我不敢赌第二次。

　　反常识结论来了：你别信什么“同城双活”，更别碰“异地三中心”。我们切过去之后，杭州到深圳链路延迟突增时，binlog传输不是断，是假活——看起来IO_THREAD还在running，实际上Seconds_Behind_Master显示0，但show master status的File_Pos已经停滞。抓包一看，全是TCP retransmit，窗口缩到1448字节。那会儿我盯着tcpdump窗口看，右下角时间跳到04:11:55，雨忽然停了。空调开始滴水，一滴、两滴、三滴……我数到第七滴时，那个延迟毛刺终于消失了。可第七滴水到底跟故障恢复有没有关系？这个我真不知道，也不打算验证。

　　小陈昨天问我：“要不要给新来的实习生讲讲那次崩盘？”我说不用。他点头，转头把笔记本合上，封皮上贴着一张便签，写着“勿忘2023.11.X”。我瞥见那个X涂改过两次，第一次写的是7，第二次改成9，第三次又刮掉重写了——但最后那个字又被咖啡泼过，只剩半撇。算了，不看了。

　　接下来两周，我要盯紧那个新开的consensus group——不是ZooKeeper，也不是etcd，是我们自己用raft库封装的轻量层，只管coordination，不碰data。目前没出事。但我昨天在gdb里调试时发现它有个bug：当leader选举期间收到两个并发的proposal，第二个proposal的term会覆盖第一个的last_log_index，导致后续日志回滚。我已经提了patch，但还没merge。所以现在每天凌晨两点，我会手动kill一次coordinator，逼它重新选主，看能不能复现问题。要是下周还活着，我就申请把这玩意儿切进生产。要是死了……那就继续吃韭菜盒子，等雨再下。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!