MySQL高可用架构：10年实战从单点到自动容灾

　　去年国庆那会儿，我原以为把MySQL从单点改成主从复制就稳了，结果大半夜被甲方电话炸醒——他们后台页面卡在加载条转圈，订单数据全堵在主库写不进去。我爬起来看监控，从库延迟飙到三万秒，主库CPU直接干到99%，连SSH都连不上。当时我盯着屏幕直骂，这破架构十年前就该淘汰了，可甲方非说“主从够用了，省预算”。

　　其实那会儿我手里有三个项目都在用主从，两个是电商，一个是金融。电商的从库延迟还能扛，毕竟用户下单有缓冲；金融那个可要命，转账记录必须实时同步，结果从库延迟两分钟，财务对账对到凌晨三点，差点把系统搞崩。我跟甲方吵了半个月，最后他们咬咬牙上了MHA——就是那个自动故障转移的工具，结果你猜怎么着？第一次主库宕机，MHA确实切过去了，可切换过程中丢了五笔订单数据，甲方直接拍桌子：“这比宕机还严重！”

　　手机这会儿快没电了，办公室空调吹得我胳膊发冷。我翻了翻聊天记录，发现十年前我刚入行那会儿，大家还在用Keepalived+VIP搞高可用，主库挂了得手动切IP，切慢了应用就挂。后来有了MHA，再后来是Orchestrator，现在都在玩ProxySQL+Group Replication。可说到底，这些工具再牛，也架不住业务量暴涨——去年双十一，有个客户的订单量比平时翻了二十倍，主库直接跪了，从库延迟到第二天才追上，那会儿连MHA都救不了场。

　　其实我最烦的是那种“伪高可用”方案——比如用Docker跑MySQL，主库挂了自动拉个新容器，结果数据没同步，新主库一上线，应用全报错。我有个同事去年就踩了这坑，甲方非要用K8s管数据库，他劝了半个月不听，结果大促当天主库挂了，K8s自动拉了个新实例，可数据还是旧的，订单系统直接瘫痪，烧了不少钱赔违约金。后来那同事跟我说：“以后再也不跟甲方争论技术选型了，他们要啥给啥，出事了让他们自己扛。”

　　但话说回来，这十年我见过最稳的架构，还是去年帮一个银行客户搞的自动容灾方案——他们用ProxySQL做读写分离，Group Replication做数据同步，外带一套自定义的监控脚本，主库挂了自动切从库，切不过去就回滚到上一个时间点的数据。那套方案跑了大半年，主库宕机了三次，每次切换时间都在十秒内，数据零丢失。甲方那个CTO跟我喝酒的时候说：“十年前我们用主从，每次宕机都得跪着求运维；现在用自动容灾，运维可以躺着睡觉了。”

　　窗外天黑了，我翻了翻今天的监控，发现有个客户的从库延迟又飙到了一万秒。我原以为上了MHA就万事大吉，结果发现他们根本没调过参数——从库的并行复制没开，binlog格式还是STATEMENT，这种配置能不延迟吗？我打电话给他们的运维，那哥们儿还在打游戏，说“啊？延迟高？我重启下从库试试。”我直接挂了电话，心想这十年高可用架构演进这么快，可有些人的脑子还是停留在十年前。

文章配图，仅供参考

　　下一步我打算试试MySQL InnoDB Cluster，就是那个用MySQL Router+Group Replication+MySQL Shell的方案。听说它能自动检测主库故障，自动选举新主库，还能自动同步数据，比MHA稳多了。不过我也有点慌——毕竟十年前我也这么信过MHA，结果还是栽了跟头。可话说回来，高可用这玩意儿，不试新东西，永远只能停留在十年前的水平。至于能不能成？管他呢，先试了再说，反正出事了还有甲方扛着。

（编辑：站长网）

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