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

　　去年一月那场故障，我现在想起来还后槽牙发酸——主库磁盘IO突然卡死，监控系统愣是没在三秒内触发自动切换，等运维小哥冲进机房手动操作时，业务已经丢了十七分钟的订单数据。那会儿我正盯着显示器上的校样改标题，被领导六十秒语音轰得脑仁疼：“不是说高可用架构能扛住任何故障吗？这十七分钟怎么解释？”

　　我原以为自动容灾设计最大的坑是脑裂，结果发现最要命的是“假死”。去年那套MHA+Keepalived的方案，理论上是能自动检测主库异常并切换的，可实际运行中，主库卡在IO Wait状态时，VIP居然没飘走——后来查日志才发现，Keepalived的check脚本里只检测了MySQL端口是否存活，没测实际查询响应时间。这就好比医生只摸病人脉搏，不管他是不是昏迷——脉搏还在跳，人可能已经凉了。

文章配图，仅供参考

　　但话说回来，自动容灾设计里“优胜劣汰”的逻辑是真站得住。我们后来把MHA换成了Orchestrator，Keepalived改成了ProxySQL+VIP，最关键的是在check脚本里加了“实际查询超时检测”——现在主库只要卡顿超过五秒，VIP立马飘走，切换时间从十七分钟压缩到八秒。上个月测试故意拔了主库的网线，业务中断时间连监控系统的报警阈值都没触发，领导看着报表直乐：“这数据波动还没下午茶奶茶销量大。”

　　不过自动容灾也不是万能药。去年有个客户非要上Galera Cluster，说“多主同步肯定比单主更可靠”。结果三个月后，他们数据库因为网络分区裂成了三个孤岛，每个孤岛都以为自己是老大，疯狂往业务表里写数据，最后数据冲突得连ETL都跑不通。我飞去现场帮他修复时，那哥们蹲在机房地上抽烟：“早知道听你的用主从复制了，这破多主同步，修复起来比写代码还难。”

　　说到这儿得吐槽下某些“高可用方案”的宣传——动不动就说“99.999%可用性”，可实际运行中，网络抖动、磁盘坏道、内核BUG这些“小问题”，哪个都能把自动容灾打成筛子。我见过最离谱的案例是，某银行的主库因为内核参数没调好，导致TCP连接堆积，自动切换脚本检测到连接数超标，直接把VIP飘走了——结果备用库的连接数也跟着飙升，最后整个集群都挂了。那天的故障报告写了二十页，最后结论就一句话：“别迷信自动，该手动干预时别犹豫。”

　　现在我跟团队定规矩：自动容灾设计必须满足三个条件——第一，故障检测要准（不能误报也不能漏报）；第二，切换逻辑要简单（越复杂的方案越容易出问题）；第三，必须留手动干预接口（自动搞不定时，人得能接管）。去年那套新架构能扛住拔网线的测试，就是因为这三点都做到了——检测用实际查询超时，切换只改VIP不碰数据，手动干预通过ProxySQL的API就能操作。

　　对了，上周领导又发来六十秒语音，说新上线的业务要“更高可用”。我听着那语音直犯怵——这年头，没有最高可用，只有更高可用，可自动容灾的边界到底在哪？我敢打包票的是，再复杂的自动方案，也扛不住运维小哥手抖删错了表；但我也说不准，等哪天AI运维普及了，这问题会不会自己解决。反正现在，我先把手头的ProxySQL参数再调调，省得下个月又被领导骂。

（编辑：站长网）

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