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

　　去年春天那MySQL高可用架构的活儿，改到第九版的时候，我盯着屏幕里那个「自动容灾」的流程图，突然觉得这玩意儿跟前端切图似的——你永远不知道甲方会在哪个像素上卡你。当时产品经理举着手机说「你看竞品都支持三节点自动切换了」，我原以为他懂技术，结果他连主从复制和GTID的区别都说不清，就盯着人家官网那句「99.99%可用性」死磕。

　　那会儿我们团队刚把单点故障的方案推翻，正在搞自动容灾的原型。前端小王凑过来问：「这状态机是不是得标红？」我瞅了眼他显示器——色偏得厉害，那红都快成橙了。「别纠结颜色，先看逻辑。」我指了指流程图里那个「故障检测」模块，「这玩意儿要是漏报，整个容灾就废了。」小王哦了一声，转头继续调他的栅格间距，切图文件夹里全是「button_normal_v2_final_改.png」这种命名，看得我头疼。

　　说回架构本身，我始终觉得「优胜劣汰」是硬道理。比如我们最初用Keepalived做VIP切换，结果发现网络分区时它会脑裂——主备同时抢VIP，数据直接乱套。后来换了MHA，虽然能自动failover，但配置复杂得离谱，光是ssh免密登录就得折腾半天。最后咬牙上了Orchestrator，这玩意儿能自动识别复制拓扑，故障时还能按权重选新主，才算把问题按住。但你猜怎么着？产品经理非说「用户看不懂权重算法」，要我们改成「按节点编号顺序选主」——我差点把数位笔的笔尖戳进屏幕，那玩意儿刚换过，挺贵的。

　　改到第五版的时候，测试组报了个诡异的问题：容灾切换后，部分查询会卡住。我查了半天日志，发现是Orchestrator在切换时没及时更新mysql.gtid_executed表，导致从库应用日志时卡在某个事务上。这问题在测试环境重现率不到5%，可上线后第一周就触发了三次——每次都是凌晨两点，运维小哥在群里喊「又挂了！」，我盯着手机屏幕，窗台上的绿萝都枯了半盆，都没心思浇水。

　　后来我们怎么解决的？简单粗暴：在Orchestrator的回调脚本里加了个「flush tables with read lock; unlock tables;」——虽然会影响毫秒级性能，但至少不会卡查询了。产品经理知道后说「这不符合最佳实践」，我直接怼回去：「最佳实践能保证不丢数据吗？能保证故障时秒级恢复吗？」他不说话了，低头刷短视频，外放声音大得离谱，我都能听见「家人们，点赞过万我跳河」这种台词。

　　最搞笑的是第七版，我们为了「提升用户体验」，在监控面板上加了「容灾进度条」——从0%到100%，显示当前切换步骤。结果前端小王把进度条的颜色调成了渐变紫，说是「符合甲方审美」。我盯着那紫色看了十分钟，突然想起色板里那个说不清的灰——当初为了这个灰，设计组和产品组吵了两天，最后选了个谁都不满意的中间值。现在倒好，进度条用紫色，监控数据用蓝色，告警用红色，整个面板像打翻了调色盘。

文章配图，仅供参考

　　现在回头看，这架构能跑起来，靠的不是什么「高可用设计原则」，而是「踩够足够多的坑」。比如我们最初没考虑半同步复制，结果主库crash后从库丢了10秒的数据；比如没做读写分离，容灾切换时应用层还在往旧主写，直接报错；比如没监控Orchestrator的心跳，它挂了半天我们都没发现——这些坑，光看文档是避不开的，必须得实际摔几次，才知道哪儿疼。

　　最近我在看新的ProxySQL方案，据说能自动路由读写请求，还能做连接池。前端小王听了说「这跟我们的组件库似的，不断迭代」。我笑了笑——组件库迭代最多改改样式，MySQL架构迭代可是要命的事。上周运维小哥还问我：「要是下次再出问题，咱们能不能直接回滚到单点？」我盯着他电脑上的切图命名——「header_bg_v3_最终版_真的不改了.png」——说：「回滚？你见过谁把拆了的房子再盖回去的？」

　　现在这架构还在跑，偶尔出点小问题，比如Orchestrator的日志轮转没配好，导致磁盘占满；或者从库的relay log没清理，空间不足。但至少没再出过数据丢失的大事故——这大概就是「优胜劣汰」的终极意义：不是完美无缺，而是比之前更抗造。至于产品经理说的「100%可用性」？我早不纠结了——连显示器都有色偏，哪有什么绝对正确的事？

（编辑：草根网）

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