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

　　去年11月那波流量掉得邪乎，我原以为又是哪个友链被拔了，结果查日志发现主库挂了——对，就是那个从2017年用到现在的单点MySQL，连个从库都没配。运维小哥蹲在服务器前拆风扇，说噪音大得像拖拉机，我盯着屏幕上的502页面，外卖盒堆在桌角都快发霉了。

　　说起来这单点架构能活七年，我自己都佩服。2017年刚接手时，老板说“先跑起来再说”，我硬着头皮用单库撑了三年，直到某天凌晨三点被电话吵醒——主库磁盘满了，业务直接停摆。那会儿连备份都是手动scp，恢复时发现半个月前的备份文件居然是0字节，我蹲在机房地上改robots.txt，把降权的页面全屏蔽了，手都在抖。

　　后来咬着牙上了MHA，结果第一次主从切换就翻车。从库同步延迟了17秒，切换后订单数据丢了32条，客服部差点把工位掀了。我查了半天发现是binlog格式没统一，ROW模式和STATEMENT模式混用，这个我敢打包票——当年为了兼容老系统，特意留的坑，结果把自己埋了。

　　键盘上掉了两个键帽，是“F”和“J”，每次登后台都得眯着眼找光标。上周改301重定向，把测试环境的配置推到生产了，流量掉得比股票熔断还快。老板在群里@我：“这曲线比A股还刺激”，我盯着显示器上贴的便签——上面写着“主从同步检查清单”，字迹都被咖啡渍糊了。

文章配图，仅供参考

　　跟客户解释这些破事儿最头疼。他们只关心“为什么昨天能搜到，今天就没了”，谁管你主从延迟还是脑裂？有次甲方爸爸直接甩来一张截图：“你们收录掉了37%！”我查了半天发现是蜘蛛抓取频次被限了——因为前一天我改过nginx配置，把爬虫的User-Agent写错了，这个我说不准算不算技术债，反正后来赔了半个月的流量。

　　窗外下了一下午的雨，运维小哥终于把风扇换好了。我翻着七年的监控日志，发现个有意思的事：每次架构升级后，流量都会掉10%左右，但三个月后总能涨回来。比如2019年从单点到MHA，2021年上Orchestrator，2023年搞多活，每次都是先跌后涨，像极了A股的“黄金坑”。

　　但多活也不是万能的。去年双十一前夜，我们做全链路压测，结果上海机房的网络抖动，触发自动容灾把流量切到北京，结果北京的Redis集群扛不住，直接雪崩。那天我改了一晚上配置，验证码输错了八次，最后发现是时区设置错了——上海和北京的NTP服务器不同步，这个坑埋得比主从延迟还深。

　　现在回头看，这七年最值钱的经验就一条：别信什么“最佳实践”，都得靠血泪喂出来。比如我们现在用ProxySQL做读写分离，但测试环境打死不用，因为去年在测试环境跑ProxySQL，把生产库的连接池搞爆了，这个教训够我吹三年。

　　服务器风扇又开始响了，我瞄了眼监控——主库的QPS刚破5万，从库延迟3秒。运维小哥说要不要加个从库，我摆摆手：“先等等，等这波流量过去再说。”他可能觉得我保守，但我知道，有些坑，得等它自己冒出来再填——就像七年前那个单点MySQL，谁想得到它能活到现在？

　　显示器上的便签又多了一张：“检查ProxySQL的query_rules”——字迹歪歪扭扭，像是用左手写的。外卖盒堆到了第五层，键盘上的“F”键还是找不到。我打开MySQL Workbench，准备给新来的实习生演示主从切换，结果发现从库的server-id和主库一样——得，又得重来一遍。

　　至于自动容灾？我现在只信一条：能活下来的架构，不是因为它完美，而是因为它能扛住你所有愚蠢的操作。就像那个用了七年的单点MySQL，要不是去年11月那波流量，它可能还在跑——而我们现在讨论的“优胜劣汰”，不过是在给自己的失误找借口罢了。

　　下周准备把上海机房的MySQL升级到8.0，运维小哥说要不要先做沙盒测试，我笑了笑：“测个屁，直接上——反正掉流量也不是第一次了。”他可能觉得我疯了，但我知道，有些坑，不亲自踩一遍，永远不知道有多深。

（编辑：草根网）

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