MySQL高可用架构：单点故障到自动容灾实战

　　工位上的键盘声吵得我头疼，手机又亮了一下——运维群在喊“MySQL主库又挂了”。这已经是这月第三次了，我原以为之前做的MHA方案够稳，结果每次故障切换都卡在VIP漂移那步，等运维手动介入的时候，接口已经超时了一堆。说白了，什么高可用架构，在真实故障面前就是个纸老虎，优胜劣汰的道理，在MySQL这儿也一样——你方案不够狠，故障就教你做人。

　　记得2025年6月那次大故障，起因是主库的磁盘IO突然飙到90%，监控没细看，等报警弹出来的时候，从库已经落后了三千多条binlog。MHA脚本倒是启动了，可VIP漂移的时候卡在了网络层——运维说防火墙规则没同步，VIP在旧节点上挂着下不来。我当时盯着屏幕上的“Waiting for server to connect”，心里直骂娘：这破脚本连重试机制都没有，卡住了就傻等，跟个木头桩子似的。

　　咖啡凉了，我端起来抿了一口，苦得直皱眉。前端小张凑过来问：“后端又崩了？”我白了他一眼：“MySQL主库挂了，你们接口报500正常。”他撇撇嘴：“那你们赶紧修啊，产品那边催着呢。”我气得想摔杯子：“修？怎么修？VIP卡在旧节点，新主库连不上，除非重启防火墙服务——可重启了万一其他服务受影响呢？”他耸耸肩走了，留下我在工位上继续骂老代码：MHA的VIP漂移逻辑写得跟屎一样，连个超时重试都没有，故障来了就只能干瞪眼。

文章配图，仅供参考

　　窗外的天黑了，运维群又弹了条消息：“VIP终于漂过来了，服务恢复中。”我看了眼时间，从故障发生到恢复，整整花了二十七分钟。这二十七分钟里，接口超时率飙到了85%，缓存击穿了一堆，连灰度环境的流量都被波及了。产品经理在群里@我：“这次故障影响太大了，下次能不能提前预防？”我回了句：“预防？怎么预防？磁盘IO突然飙高这种事儿，谁能提前知道？”他没再回，可能去骂运维了。

　　其实我也知道，光靠MHA确实不够。上周我试了试Orchestrator，发现它的故障检测和切换逻辑比MHA狠多了——它直接监控MySQL的复制状态，一旦发现主库不可用，立刻在从库里选一个最合适的提主，然后通过GTID自动同步数据，连VIP都不用漂。我原以为这方案够稳，结果测试的时候发现，如果从库的数据落后太多，Orchestrator会卡在“Waiting for slave to catch up”这一步，等它同步完，故障都过去半小时了。

　　工单系统又弹了条消息，是测试组提的bug：“MySQL故障切换后，部分历史数据丢失。”我点开一看，原来是MHA在切换的时候，没等从库完全同步就提了主，导致最后几百条binlog没应用。我气得直拍桌子：这破脚本连数据一致性都不保证，还搞什么高可用？后来我查了下，MHA的默认配置是“尽快切换”，如果想要强一致性，得手动改配置——可谁没事儿会去改默认配置啊？

　　其实我现在有点迷茫。MySQL的高可用架构，到底该怎么搞？MHA简单但不够稳，Orchestrator稳但配置复杂，ProxySQL能代理流量但增加了延迟。我原以为选个成熟的方案就能高枕无忧，结果每次故障都能暴露出新问题。说白了，没有完美的方案，只有更适合业务的方案——你得根据QPS、数据量、网络环境这些因素，选个最能扛的。可问题是，这些因素随时都在变，今天能扛的方案，明天可能就崩了。

　　咖啡喝完了，我起身去接水。路过运维工位的时候，听见他在吐槽：“这MySQL高可用，搞了这么多年还是这样，每次故障都得手动介入。”我笑了笑：“可不嘛，自动容灾？哪有真正的自动，都是故障教做人。”他点点头：“下次试试Orchestrator？”我耸耸肩：“试试呗，反正MHA已经不行了。”

　　回到工位，我打开电脑，准备再研究研究Orchestrator的配置。窗外的天已经全黑了，键盘声还是那么吵。我想，也许明天该跟团队开个会，讨论下到底该用什么方案——毕竟，优胜劣汰的道理，在MySQL这儿也一样，谁更稳，谁就能活下去。

（编辑：站长网）

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