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

　　昨天接口超时告警炸锅那会儿，我正蹲在茶水间啃冷掉的煎饼果子——监控大盘上那条绿色的线抖得跟帕金森似的，老张举着手机冲进来喊"主库又挂了"，咖啡渣溅了他半袖子。这场景我熟，八年前第一次碰高可用的时候，也是这么手忙脚乱，只不过那会儿是单点，现在好歹能自动切了。

文章配图，仅供参考

　　工位隔断上贴的便签都卷了边，上面还记着2018年那次雪崩——缓存击穿加上慢查询，QPS从两万直接掉到三位数，DBA老李抱着笔记本在机房蹲了半宿，机箱嗡嗡响得像拖拉机。那会儿我们还在用ProxySQL，配置文件里连注释都是手写的，改个参数得重启服务，结果回滚的时候把另一个业务的连接池搞崩了，产品总监在群里@所有人："谁动了我的报表？"。

　　但说真的，这八年最明显的感受是"优胜劣汰"——不是架构本身多牛，是那些扛不住的方案早被淘汰了。比如最早用keepalived做VIP切换，心跳间隔设30秒，结果网络抖动的时候VIP跟幽灵似的飘来飘去，前端妹子投诉说"页面一会儿能提交一会儿不能，跟抽风似的"。后来改用Corosync+Pacemaker，配置复杂得能写本小说，但至少切换时间压到了10秒内——虽然还是会被产品骂"太慢"，可总比之前好。

　　外卖筷子掉在地上那会儿，我突然想起2020年那次灰度发布——新架构刚上线，监控还没全接，主库突然挂了。按理说应该自动切到从库，结果Orchestrator的集群检测脚本卡在"pending"状态，等了五分钟才触发切换。那五分钟里，所有写请求全堆在消息队列里，等服务恢复的时候，定时任务和用户请求撞在一起，直接把数据库连接池打爆了。后来我们给Orchestrator加了重试机制，又把检测间隔从5秒调到2秒，可老张说："治标不治本，哪天要是网络分区，该挂还得挂。"

　　运维小哥在工位上打电话谈房租，声音大得能盖过机箱风扇——他说房东要涨租，可他刚给家里换了辆电动车。这让我突然意识到，高可用这事儿和租房有点像：你永远不知道明天会不会被赶出去，所以得提前找好下家。比如我们现在用Group Replication，数据强一致，自动选举，可每次选举的时候，日志刷得太快，监控里根本看不清谁当了新主库。有次切换后发现有个表的字符集不对，原来是切换前夜有开发偷偷改了表结构，没走灰度流程。

　　产品那边又在改需求，这次是要把"点赞"功能从异步改同步——说是为了"用户体验"。我盯着屏幕上的堆栈信息，心想这帮人根本不知道，同步写会多多少锁等待，多多少慢查询。八年前我们连索引都舍不得加，现在倒好，为了个"实时性"能把数据库搞崩。老李说："要不咱们限流吧？"可产品总监拍桌子："限流会影响转化率！"——最后我们妥协，在应用层加了缓存，可缓存穿透的时候，数据库还是得扛，这时候高可用架构再牛，也挡不住业务瞎搞。

　　我原以为自动容灾是终点，结果发现它只是个起点。比如现在用K8s管理MySQL，Pod挂了能自动拉起，可数据文件挂载到共享存储上，万一存储坏了，整个集群都得凉。去年双十一前，我们做压测，把QPS压到平时的10倍，结果发现自动切换虽然快，但切换后连接数暴增，把操作系统文件描述符打满了——最后是运维小哥连夜改了sysctl.conf，才没让系统崩溃。可这事儿谁敢跟产品说？他们只会问："为什么昨晚响应时间多了50ms？"

　　咖啡机坏了那会儿，老张说："要不咱们回退到单点吧？至少出了问题知道该骂谁。"我笑了——八年前我们骂单点不稳定，现在骂自动容灾不可靠，可骂归骂，该上的还得上。就像昨天超时告警的时候，我们一边骂Orchestrator的选举机制，一边检查GTID是否连续，一边给产品发消息："服务已恢复，但部分数据可能有延迟"。产品回了个"哦"，然后继续改他的需求文档。

　　现在想想，高可用这事儿没有完美的方案，只有"暂时没出问题"的方案。我们做的所有优化，不过是在"出问题"和"没出问题"之间，把概率往后者挪了挪。比如现在用ProxySQL做读写分离，可读写分离本身就会带来主从不一致；用半同步复制，可半同步也可能退化成异步；用自动故障转移，可转移的时候也可能丢数据——但这些都不重要，重要的是当问题真的来的时候，你能比八年前更快地恢复服务，哪怕只是快那么几分钟。

　　机箱还在嗡嗡响，监控大盘上的绿色线终于稳了。老张说："要不咱们下次把日志级别调低点？刷得太快看不清。"我点点头，心想：是啊，看不清又怎样？反正该出的问题，迟早会出。我们能做的，不过是让下次出问题的时候，别那么手忙脚乱罢了。

（编辑：站长网）

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