MySQL高可用架构:110年实战的自动容灾演进
|
三个月前那场MySQL架构评审,我原以为要跟运维撕到下班——结果他们自己先吵起来了。老张拍着白板喊“主从切换必须人工确认”,小王举着手机说“灰度环境已经跑通自动failover”,我盯着空调滴在需求单上的水渍,心想这破投影仪对焦不准的毛病怎么还没修。
文章配图,仅供参考 那标题你们也看到了,“110年实战的自动容灾演进”。我第一反应是这帮人是不是把MySQL的版本号和人类寿命搞混了——后来发现他们真把从MySQL 3.23到8.0的演进史翻出来了。但最狠的不是这个,是他们用“优胜劣汰”四个字把所有争议都拍死了:人工干预的方案?淘汰;需要手动触发的切换?淘汰;连“先通知运维再切换”这种中间态都被归到“过渡方案”里——就跟当年功能机被智能机淘汰一样,甭管你多稳,只要不是全自动,就是落后生产力。我原以为自动容灾最大的坑是数据一致性——结果他们用GTID和半同步复制解决了。我原以为最大的阻力是运维不愿意交权——结果发现是开发自己不敢信机器。老张举着打印的需求单说:“你们记不记得去年双十一?主库挂了,值班运维睡过头,切换花了17分钟,订单系统积压了3万单。”小王补刀:“而灰度环境那次自动failover,从检测到主库无响应到切换完成,用了23秒。”我盯着桌上那摞需求单——最上面那张还是我三个月前写的“优化埋点上报逻辑”,现在连PRD都找不到了。 但最魔幻的是他们怎么论证“110年实战”。小王翻出一张泛黄的文档照片:“这是2003年淘宝用的MySQL主从方案,当时靠crontab每5分钟检查主库状态。”老张冷笑:“那会儿连半同步复制都没有,从库延迟半小时都是常事。”然后他们开始掰扯:2008年MHA出来,2012年Orchestrator,2015年Group Replication,2018年InnoDB Cluster——每个节点都对应一次“人工干预被淘汰”的案例。我手机震了三次,都是测试说“埋点数据又丢了”,我回了个“等会”,抬头看白板,发现他们已经画到“2023年用ProxySQL+Orchestrator+Prometheus的自动容灾链”了。 空调还在滴水,我挪了挪椅子——少一把,不知道谁搬走了。小王突然说:“其实我们漏了个关键点:自动容灾的前提是监控得够准。”老张拍桌子:“所以Prometheus的告警规则我们调了11版!”我插嘴:“那灰度环境那次误报呢?主库明明活着,Prometheus说它挂了。”他们愣了两秒,老张说:“那是阈值设得太紧”,小王说:“所以现在用多维度检测——连接数、QPS、慢查询、心跳包。”我心想:这不就是把“人工判断”拆成算法了吗?但没说出口——反正他们已经用“优胜劣汰”把所有反驳堵回去了。 跑题说个事:上周我审一个新功能的PRD,里面写了“优化用户注册流程,减少填写字段”。开发说这是“提升转化”的高优需求,结果上线后注册量没涨,反倒是客服接到一堆“为什么收不到验证码”的投诉——原来他们把手机号输入框从“必填”改成“选填”了。我拿着数据找产品,他说:“可能用户觉得选填就不用填了?”我盯着他电脑上的漏斗图,心想这跟MySQL自动容灾有啥关系?哦对了,那功能现在没人用,但排期表里还写着“持续优化”。 回到评审会。老张突然问:“那自动容灾的ROI怎么算?”小王翻出一张表:“去年人工切换导致的故障,平均每次损失12万;自动容灾的灰度环境,已经避免了3次潜在故障。”我算了下:12万×3=36万,而他们为这套系统投入的人力,光算开发就超过200人天——这账怎么算都不划算。但老张说:“你不能只看直接损失,还要算品牌影响、用户流失。”我小声说:“可用户根本不知道我们用了自动容灾啊。”他瞪我:“所以这是基础设施,不是功能!” 会议室的椅子确实少一把。我挪到角落,听他们继续掰扯“自动容灾要不要保留手动切换按钮”。老张说:“必须保留,这是最后一道保险。”小王说:“保留就意味着有人会依赖它,那自动容灾的逻辑就可能被绕过。”我突然想起上周那个没人用的功能——当时我们也在“要不要保留旧流程”上吵了半天,最后产品说“先留着,灰度观察”,结果现在旧流程的使用率是0.3%,但没人敢删。这跟MySQL的“过渡方案”是不是有点像? 最后他们达成共识:自动容灾是必须的,但保留一个“紧急手动切换”的隐藏入口——类似飞机上的手动驾驶模式。我举手:“那这个入口的权限怎么管?”老张说:“只有运维组长有。”小王补:“而且要双因素认证。”我低头看手机,测试又发消息:“埋点数据还是丢,是不是你们改了什么?”我回:“没改,可能是网络问题。”抬头看白板,他们已经在写“下一阶段:AI预测主库故障”了。 散会时我拿了三张需求单——我的“优化埋点上报逻辑”、产品的“提升注册转化”、测试的“修复数据丢失”。空调不滴水了,但地上还是湿的。我突然意识到:所谓“110年实战的自动容灾演进”,本质上就是一群人用更复杂的技术,把“人工判断”拆成机器能执行的规则——而规则的漏洞,总要靠下一轮技术来补。就像我们做的功能,不管多努力优化,总会有用户用出我们想不到的方式——或者根本不用。 现在的问题是:我要不要把那三张需求单扔了?反正没人看。但测试的“数据丢失”问题得解决——可能得找运维查MySQL的binlog。而运维现在应该在研究怎么把“紧急手动切换”的权限从组长下放到主管——毕竟组长也可能睡过头,像去年双十一那样。 (编辑:草根网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |






浙公网安备 33038102330471号