MySQL高可用架构：17年实战防单点故障

文章配图，仅供参考

　　窗外雨下得跟倒水似的，风扇在旁边嗡嗡转，我敲键盘的手都在抖。这时候测试小李在群里发了张“裂开”的表情包，我骂了句“别添乱”，转头跟小王说：“先别急着切，把写流量全切到从库B，主库只读。”他瞪眼：“从库B？那玩意儿不是只做备份的吗？”我翻出历史监控：“看清楚，从库B的同步延迟从来没超过五秒，而且它没跑过DDL，数据绝对干净。”他半信半疑去操作，结果刚切完，订单量突然暴涨——原来产品刚上了个限时活动，流量跟潮水似的涌进来。从库B的CPU直接飙到九十，读请求开始排队，页面白屏率蹭蹭往上涨。

　　我盯着监控曲线，突然想起三年前那次事故——当时用的MHA架构，主库挂了自动failover，结果备库接管后发现二进制日志没对齐，整个集群瘫了四小时。那次之后我死活不信自动切换，宁可手动操作，哪怕慢点。现在这情况，从库B眼看要撑不住，我咬咬牙：“把读流量再分一半到从库C，写流量还是锁在B。”小王喊：“从库C的延迟有二十秒！”我吼：“二十秒总比数据错乱强！先扛过这波流量再说！”

　　这时候编译进度条卡在百分之九十，我敲了敲桌子骂：“这破机器，每次高并发就掉链子。”小李凑过来：“要不试试ProxySQL的读写分离？我记不清哪个版了，好像能自动检测节点状态。”我白他一眼：“你当这是实验环境？线上敢随便换中间件？”话虽这么说，我还是偷偷翻了翻ProxySQL的文档——记不清是记不清，但去年灰度测试时，它确实能根据延迟自动路由请求，比手动切灵活多了。只是当时觉得“没必要”，现在想想，可能真是自己太保守。

　　外卖到了，我扒拉两口饭，继续盯监控。从库B的CPU终于降下来，读请求排队消失，订单量慢慢恢复正常。小王松了口气：“幸亏没切备库，不然现在得被产品骂死。”我哼了一声：“别高兴太早，主库还没修好呢。”他问：“那现在怎么办？”我指了指屏幕：“等流量下去，先把主库的磁盘IO问题查了——我怀疑是索引碎片太多，导致写性能下降。然后从库B和C，一个当热备，一个当读扩展，ProxySQL的配置先留着，下次大促前灰度试试。”

　　说到这儿，我突然想起十七年前刚入行那会儿——那时候哪有什么高可用架构？主库挂了，运维半夜爬起来扛着服务器去机房换硬盘，开发在旁边干着急。后来用了主从复制，结果同步延迟导致数据不一致，被测试揪着骂了半个月。再后来试过Galera Cluster，写冲突解决得脑壳疼；试过Orchestrator，监控粒度不够细；试过MGR，网络分区时直接分裂成两个集群……这些年踩过的坑，比吃的饭还多。

　　但为什么最后还是选了“主库+从库+手动切换”这种“老古董”架构？因为优胜劣汰啊。自动failover的方案看着美，但线上环境太复杂——网络抖动、磁盘故障、DDL卡同步、中间件bug……任何一个小问题都能让自动切换变成灾难。反而是这种“半自动”的架构，虽然麻烦点，但每个环节都可控，出了问题能快速定位，修复后还能复盘优化。就像去年那次事故，如果当时用了MHA，可能现在还在查数据错乱的原因；但手动操作，虽然手忙脚乱，至少数据没丢，用户没骂太狠。

　　当然，我也知道这架构有局限——比如切换时确实有延迟，比如需要人工干预，比如对运维要求高。但线上环境哪有完美的方案？都是权衡利弊后的妥协。就像现在，我一边骂ProxySQL的配置麻烦，一边偷偷研究它的自动路由功能；一边嫌从库B的延迟高，一边给它加监控告警；一边说“手动切换最稳”，一边给切换脚本加更多校验逻辑。说白了，高可用架构不是选个工具就完事，而是得根据业务特点、团队能力、历史事故，不断调整优化——优胜劣汰，适者生存。

　　对了，刚才说到编译进度条——它终于动了，但卡在百分之九十九不动了。我敲了敲键盘，骂了句“艹”，转头对小王说：“等会儿帮我看看，这破机器是不是该换固态了？”他头也不抬：“你去年就说要换，结果到现在还没批预算。”我挠挠头：“行吧，先忍忍——反正线上比这更糟的情况都扛过来了，编译慢点算啥。”

（编辑：我爱资讯网）

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