MySQL高可用架构：17年运维实战容灾设计

　　去年8月份那场故障，我现在想起来还后怕——主库的GTID卡在半同步复制的队列里，从库的IO线程早挂了，监控居然没报红。老张叼着烟在机房转了三圈，最后把备用库的relay log直接scp过去，结果半路上SSH断了，数据包裂成碎片，从库直接跪了。那天中午盒饭里有块姜，我嚼着姜丝在故障报告里写“优胜劣汰”，写到第三行突然笑出声——这词儿用在这儿太他妈合适了，MySQL的高可用架构，活下来的哪个不是踩着尸体上来的？

　　车间那台风扇一直在响，嗡嗡的跟老张的鼾声似的。他说MHA那套方案早该淘汰了，我原以为他是嫌配置麻烦，结果他翻出2017年的运维日志——当时用MHA做主从切换，结果网络分区把VIP漂移到从库上，从库的binlog还没追上主库，应用层直接开始写脏数据。那天他蹲在机房地上改配置，手套上一块硬掉的胶，是上周粘网线时蹭上的。“你看，”他指着日志里的时间戳，“主从延迟3秒，MHA的脚本根本没检测到，等切换完成，数据已经乱成一锅粥了。”

　　后来我们试了Orchestrator，这玩意儿倒是能自动检测拓扑，但有个老毛病——如果从库的server_id和主库冲突，它会把整个集群当垃圾扔掉。去年10月那次故障，就是因为运维小王手滑把备用库的server_id设成了1，Orchestrator直接把主库踢出集群，应用层连了5分钟空库，DBA群里炸锅，有人说“这他妈比MHA还坑”，有人说“至少它不会写脏数据”。我蹲在机房角落修监控，手机在铁台上震了一下，是老板发来的消息：“赶紧切回MHA，至少稳定。”

　　其实我也没拆到底。去年12月试Group Replication，官方文档说“自动选主，无需外部协调”，结果我们3节点的集群，选主选了12分钟——其中一个节点的网络延迟高了20ms，GR直接卡在“Waiting for votes”状态。老张把监控曲线拍在桌子上：“这他妈叫高可用？比我家那台老式缝纫机还慢。”后来我们查源码，发现GR的选主算法对网络延迟敏感得离谱，稍微有点波动就重试。我原以为这是MySQL的通病，结果翻到Percona的文档，他们早就在5.7.17里改了选主逻辑——可惜我们用的是官方版，没打补丁。

文章配图，仅供参考

　　中午吃饭时，小王问我“为什么不用ProxySQL做读写分离？”我嚼着米饭里的姜丝，没说话。他不知道，上个月我们试ProxySQL，结果它的查询路由规则太复杂，运维小李手滑把写请求发到了从库，从库的sync_binlog没开，数据丢了半小时。那天老板在群里发火：“再搞这种花里胡哨的东西，全都滚回去用MHA！”我原以为ProxySQL能解决所有问题，结果它连最基本的路由规则都搞不定——这他妈算什么高可用？

　　现在车间里还在用MHA的，都是些老项目，新项目全上了Orchestrator+GTID。老张说这是“优胜劣汰”的必然，我倒觉得是运气——去年8月那场故障，如果备用库的relay log没裂，如果SSH没断，如果从库的IO线程没挂，我们可能还在用MHA。但现实是，这些“如果”都没发生，MHA被淘汰了，Orchestrator上位了，这就是运维的残酷——你永远不知道下一个故障会从哪儿冒出来，你只能赌，赌你的方案能扛住下一次“如果”。

　　手套上的胶硬得像石头，我搓了搓，没搓掉。老张说下周要试MGR+ProxySQL的组合，我笑了笑，没接话。这个型号我只在别人那儿见过，听说能自动检测主从延迟，自动调整路由规则——但谁知道呢？运维这行，没有绝对的高可用，只有相对的“优胜劣汰”。就像老张说的：“你永远别指望一套方案能解决所有问题，你只能祈祷，祈祷它别在你值班的时候出事儿。”

　　下午要开运维例会，老板肯定会问“为什么不用MGR”，我摸了摸口袋里的螺丝刀，心想：等会儿得把ProxySQL的坑再捋一遍，别让老板觉得我们又在搞“花里胡哨”的东西。车间风扇还在响，老张的鼾声混在里面，像极了MySQL的复制线程——你永远不知道它什么时候会停，什么时候会卡，你只能盯着监控，等着下一个故障找上门来。

（编辑：应用网_常德站长网）

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