MySQL高可用架构：9年实战的自动容灾设计

　　去年劳动节那会儿，机房空调坏了，运维小哥蹲在机柜后面擦汗，手里攥着根温度计——三十八度，MySQL主库的CPU负载直接飙到九十。我原以为自动容灾脚本能顶上，结果那破玩意儿卡在“检查从库延迟”那步，死活不肯切流量。后来翻日志才发现，监控组件的API接口被安全组给禁了，就因为上周安全团队说“所有对外端口必须关闭”。你说这帮人是不是闲的？

　　但话说回来，这九年踩过的坑里，最让我服气的还是“优胜劣汰”这套逻辑。去年双十一前，我们试过三种自动容灾方案：第一种是靠Keepalived+VIP漂移，结果网络分区时VIP在两个节点上来回跳，直接把业务干崩了；第二种用MHA，配置复杂得能写本书，运维小哥调了三天参数，最后发现是MySQL版本不兼容；第三种是现在用的Orchestrator，虽然文档写得像天书，但至少能自动识别脑裂，还能通过Grafana看拓扑图——现在运维组的人没事就盯着那图发呆，比刷抖音还上瘾。

　　那天空调坏的时候，我正跟产品老齐吵架。他非要在容灾方案里加“自动生成故障报告”的功能，说“用户需要知道为什么服务挂了”。我怼他：“用户只关心服务什么时候能恢复，你搞这花里胡哨的，万一影响切流速度怎么办？”他拍桌子：“这是KPI！”我指了指墙上挂的“稳定性第一”的横幅：“那你去跟CTO说，是KPI重要还是数据库重要？”他愣了两秒，摸出手机给老板发消息——后来听说老板回了个“先保可用性”。

　　说到脑裂，去年有次更离谱。主库和从库因为网络抖动断了连接，Orchestrator检测到主库不可达，直接把从库提了主。结果网络恢复后，原来的主库以为自己还是老大，开始写数据，从库（现在的新主）也不认它，两边数据开始分叉。最搞笑的是，监控系统没报警——因为阈值设得太高，只有当延迟超过五分钟才触发，而这次脑裂只持续了两分半。后来我们改了策略：只要检测到主从连接中断，不管延迟多少，先锁主库的写权限。这招虽然粗暴，但至少没再出过分叉事故。

　　运维组的小王有个习惯，每次切流前都要摸一下机柜——说是“感受一下温度，心里有底”。有次切流时他手滑，把电源线碰松了，主库直接断电。还好Orchestrator反应快，三十秒内把流量切到了从库。但那三十秒里，业务方的报警短信像雪花一样飞过来，产品老齐的电话直接被打爆。他后来跟我说：“那三十秒，我仿佛看到了自己职业生涯的终点。”我安慰他：“至少现在你知道，自动容灾真的能救命。”

　　不过自动容灾也不是万能的。去年上季度末，我们做压测，故意把主库的磁盘写满，想看看从库能不能自动接管。结果从库的磁盘空间也不够——因为运维小哥忘了调整监控阈值，磁盘用到百分之九十才报警，等手动扩容完，主库已经挂了十分钟。这事儿后来被拿来说了三个月，每次开会都要提：“自动容灾的前提是，你得先把基础监控做好。”

　　现在我最怕的是“伪高可用”——看着有主从、有VIP、有监控，但真出问题时，每个环节都可能掉链子。比如去年有次，主库宕机后，VIP漂移到了从库，但应用层的连接池没刷新，还是往死掉的主库发请求；还有次，从库提主后，DNS缓存没更新，部分用户还是访问到了旧主库的IP。这些坑，没有九年实战经验，根本想不到。

文章配图，仅供参考

　　至于未来？我敢打包票，自动容灾肯定会越来越智能，但坑也会越来越多。比如AI预测故障、区块链存证这些新玩意儿，听着高大上，但真用到生产环境，指不定出什么幺蛾子。所以我的建议是：先把基础的复制、监控、切流做好，再考虑花里胡哨的功能——毕竟，稳定性这东西，没有捷径可走。

　　对了，上周运维小哥又摸机柜了，这次他说：“温度正常，但感觉机柜在抖。”我们一查，原来是隔壁工位的小李在用冲击钻装架子——这算不算新的“容灾风险”？

（编辑：站长网）

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