MySQL高可用架构实战：19年经验谈自动容灾设计

文章配图，仅供参考

　　那天风扇转得特别响，空调出风口嗡嗡震，我原以为只是常规切换测试，结果主库的磁盘阵列突然掉了个盘——别问我为啥没触发RAID自动重建，后来查日志发现是固件版本有坑，这破事能说三天。从库接管时，我盯着GTID的同步延迟，眼睁睁看着它从0跳到128，再跳到512，最后卡在1024不动了。开发老张在旁边嘀咕：“这延迟曲线比我们App的启动时间还离谱。”

　　自动容灾的“自动”俩字，坑就坑在它太“自动”了。我们用的是MHA+Keepalived的组合，理论上是主库挂了，VIP自动漂移，从库提升为主库，脚本执行切换——但那天从库的relay log卡住了，MHA检测到主库无响应后，直接杀了从库的IO线程，结果从库的SQL线程还在啃半截事务，这一杀直接导致binlog位置对不上，自动切换脚本卡在“checking replication status”那行死循环了。外卖凉了的时候，我还在手动补binlog，运维小王在旁边翻白眼：“早说该用Orchestrator，你们非说MHA够稳。”

　　后来复盘，领导拍桌子问“为啥不设超时自动回滚”，我盯着代码里的“while True”沉默了三秒——这行代码是我五年前写的，当时觉得“主从切换怎么可能超过十秒”，现在看简直像在扇自己耳光。自动容灾的“优胜劣汰”就体现在这儿：你以为的“稳”，可能只是业务量没到阈值；你以为的“足够快”，可能只是没遇到极端场景。那天从库的磁盘IOPS飙到三千，我原以为是切换导致的，结果查监控发现是某个慢查询在作妖——那家伙的WHERE条件走了全表扫描，扫了三百多万行，把磁盘打满了。

　　跟开发吵了一架那事儿更离谱。他们非说“慢查询不影响高可用”，我直接把切换失败的日志甩他们脸上：“主库宕机时，从库正在执行这个慢查询，SQL线程占着锁，IO线程等不到响应，MHA误以为复制挂了，直接杀了从库——这锅谁背？”开发老李叼着烟冷笑：“那你咋不优化慢查询？”我差点把键盘砸过去：“老子要是能优化所有慢查询，还搞啥高可用？直接单库跑天下得了！”

　　后来我们改了策略：自动切换脚本里加了“检测慢查询”的钩子，如果从库有执行超过五秒的SQL，切换前先杀掉；MHA的检测间隔从三秒调到一秒，超时时间从十秒缩到五秒；还买了块SSD专门给从库的relay log用——别笑，这招真管用，上次主库重启，从库的切换延迟从二十七秒降到了三秒。运维小王看着监控说：“这波算你赢。”我白他一眼：“赢个屁，下次业务量翻十倍，这三秒照样得卡。”

　　现在想想，自动容灾的“优胜劣汰”就像达尔文进化论——不是你的架构多牛，是业务量会帮你筛选出最脆弱的环节。我们以前总觉得“主从延迟”是常态，结果那天从库的延迟直接把自动切换干废了；以前觉得“MHA够稳”，结果遇到磁盘固件坑，它连回滚都做不到；以前觉得“慢查询不影响大局”，结果它成了压垮骆驼的最后一根稻草。现在每次做容灾演练，我都盯着监控里的“切换时间”和“延迟曲线”，生怕哪个环节又冒出个“二十七秒”。

　　下一步打算把Orchestrator和ProxySQL都测一遍，MHA虽然轻量，但扩展性确实差。不过领导又提了新需求：要支持跨机房容灾——得，这波又得从头开始。窗外天黑了，屏幕上的行数还在跳，我揉了揉眼睛，突然想起那天从库卡住时，开发小妹路过问了句“好了没”，我头也没抬说“快了”，结果这一“快”就是俩小时。高可用这玩意儿，真是越搞越觉得，没有“够稳”，只有“暂时没崩”。

（编辑：站长网）

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