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

　　去年三月份那场MySQL主从切换事故，我现在想起来还后怕。当时运维小哥蹲在机房角落打电话，手里攥着根网线，背景是空调轰隆隆的噪音，外卖盒在桌上堆成小山——就这环境，主库突然挂了，从库没接上，APP直接跪了半小时。我原以为MHA方案够稳了，结果发现那套脚本根本没处理过网络分区的情况，半同步复制卡在IO线程，从库数据落后了整整三分钟。

　　后来我们咬着牙上了Orchestrator，不是因为它多牛，纯粹是被逼的。那会儿团队里有人死磕Keepalived，说VIP漂移最简单，我直接拍桌子：你们见过脑裂时VIP在两台机器上同时飘吗？上次双十一前夜，主库CPU飙到90%，Keepalived的check脚本卡住，VIP在主从之间来回跳了七次，DBA差点把键盘吃了。这种时候还敢用单点心跳检测？脑子进水了。

　　但说真的，Orchestrator也不是银弹。有次测试环境搞自动failover，它把一个延迟两秒的从库扶正了，结果业务层报了三百多个数据不一致的错误。后来查日志发现，那台从库的relay log还没apply完，就被Orchestrator的GTID比对给忽悠了。我蹲在工位上改配置，隔壁测试小妹还凑过来看热闹，说你们这破系统怎么比她男朋友还难伺候。

　　现在回头看，从单点到自动容灾，根本不是技术选型的问题，是优胜劣汰的生存法则。我见过太多团队，主库挂了先查日志，从库挂了先骂网络，等真出事故了才想起来要搞高可用。去年有个创业公司的CTO跟我吐槽，说他们用Galera Cluster，结果网络抖动导致全集群锁死，业务停了四小时。我问他：你们有监控吗？有压测吗？有故障演练吗？他支支吾吾说“正在建”——这种话我听了十八年，耳朵都起茧子了。

　　最搞笑的是，有些团队明明知道单点有风险，还硬要上。上次去客户那边支持，发现他们的MySQL主库跑在物理机上，从库是虚拟机，还是跨机房的。我问他们：这延迟得多少？运维小哥说“大概一百毫秒吧”。我差点笑出声：一百毫秒？你们知道半同步复制超时默认是十秒吗？这要是主库挂了，从库得等十秒才能接管，APP早凉透了。他挠挠头说“那我们调成五秒？”我摇摇头：调成五秒也没用，网络抖动一下照样超时，到时候还是得手动切。

　　现在我们的方案是Orchestrator+ProxySQL，主从切换自动触发，延迟超过三秒的从库直接排除。但说实话，这方案也不完美。有次主库磁盘满了，Orchestrator检测到主库不可用，自动把从库扶正，结果ProxySQL的连接池没刷新，部分请求还是发到了旧主库，又跪了十分钟。那天我加班到凌晨两点，改完配置才发现，运维小哥的外卖凉了，正蹲在楼梯间啃面包。

文章配图，仅供参考

　　现在团队里新人总问我：到底该选MHA还是Orchestrator？我通常只回一句：先想想你们能不能接受五分钟宕机。能接受，就用MHA；不能接受，就上Orchestrator+ProxySQL，但得做好监控和压测。至于Galera Cluster和Group Replication？除非你们有专职DBA，否则别碰——这些方案看起来美，但维护成本高得吓人，出了问题连Google都救不了你。

　　最后说句大实话：高可用没有终点，只有不断踩坑和填坑。我干了十八年，现在看到MySQL的错误日志还是头皮发麻。但没办法，这就是原生开发的命——你永远不知道下一个事故会在什么时候来，只能尽量让自己准备得充分一点。就像去年三月份那次，要是我们没提前测过Orchestrator的failover流程，要是运维小哥没蹲在机房随时准备拔网线，APP可能就真跪了。现在想想，还真是后怕。

（编辑：站长网）

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