MySQL高可用架构实战：8年运维的自动容灾设计

　　去年十月份那档子事儿，现在想起来还后脊梁发凉。主库突然挂掉那会儿，我正蹲在机房地上改配置，手机在裤兜里震得腿发麻——监控群里炸锅了，业务方连发二十条消息，说订单系统卡得跟蜗牛似的。我原以为只是普通的连接池耗尽，结果登录服务器一看，好家伙，MySQL的error log里全是“Too many connections”，可实际活跃会话数才三百多，明显不对劲。

　　第一反应是查慢查询，结果慢日志里干净得能当镜子用。正盯着日志发呆，隔壁工位的老张突然喊：“不对啊，这流量怎么一阵一阵的？”他甩给我一张Zabbix截图，主库的QPS曲线像心电图似的，每两分钟跳一次峰值，每次持续不到二十秒，可业务方说用户反馈卡顿持续了快十分钟。我盯着屏幕看了半分钟，突然反应过来——这他娘的不是CC攻击，是有人在玩“精准打击”啊。

　　手机又震了，是业务方总监的电话，我直接按掉——这会儿接电话准被骂得狗血淋头。转头喊老张：“快查从库状态！”我俩冲到从库服务器前，发现从库的IO线程早就断了，SQL线程还在啃着三天前的relay log。我原以为MHA早就把故障转移搞定了，结果一看MHA的日志，最后一条记录是“Checking the replicaiton of the dead master”，后面全是“No new master found”。得，自动容灾没触发，白瞎了之前熬了三个通宵做的测试。

　　这时候窗外天都亮了，泡面在桌上凉得能结油花。我边啃面边翻MHA的配置，发现“master_ip_failover_script”的路径写错了——之前改过脚本名字，没同步到配置文件里。老张在旁边骂：“这他妈不是第一次了，上次主从切换失败也是因为路径问题！”我没接话，心里直犯嘀咕：这自动容灾的脚本，写的时候觉得万无一失，可真到用的时候，一个标点符号都能要命。

　　业务方的电话又打进来，这次我没敢按掉，硬着头皮接了。总监在那边吼：“你们到底能不能修好？订单损失已经六位数了！”我咬着后槽牙说：“在修了，十分钟内恢复。”挂了电话，老张冲我挑眉毛：“十分钟？你吹牛呢？”我白了他一眼：“不吹牛他们能放过咱们？”其实我心里也没底——从库的数据落后太多，直接提主库肯定丢数据，可业务方等不起。

　　正手忙脚乱地补relay log，防火墙日志突然开始疯狂滚动，IP全是国内的，目标全是3306端口。我盯着日志看了两秒，突然乐了——这帮孙子，主库都挂了还扫呢？老张凑过来问：“笑啥？”我指了指屏幕：“你看，这攻击IP里有个是业务方的测试服务器。”他愣了两秒，突然爆粗口：“我操！他们自己人扫的？”我耸耸肩：“谁知道呢，反正现在没空查。”

　　最后是手动把从库提了主库，丢了两分钟的订单数据。业务方不依不饶，非要我们给个“根本原因分析”。我写了份报告，重点说了MHA配置错误和从库延迟，但心里清楚——真正的“根本原因”是自动容灾没经过实战检验。那些测试用例写得再漂亮，没在真实攻击里滚过几圈，都是纸糊的。后来我跟老张复盘，他说：“其实自动容灾这玩意儿，就跟灭火器似的——你希望它永远用不上，可真要用的时候，必须得能喷出水来。”

文章配图，仅供参考

　　不过话说回来，自动容灾这玩意儿，永远没有“完美”这一说。上周业务方又提需求，说要加“脑裂保护”，我听了直头疼——保护是能加，可每加一层保护，就多一层出问题的可能。现在我的原则是：能手动解决的，绝不依赖自动；必须自动的，必须经过至少三次真实故障的考验。至于那些“理论上可行”的方案，还是留给实验室吧。

　　对了，昨天又收到业务方的工单，说要把MySQL的密码改成“123456@Abc”，我直接驳回了——这帮人，上次被弱口令扫出漏洞，现在还不长记性。不过我也懒得骂了，反正骂了也没用，下次还得我擦屁股。现在我只盼着，下次主库挂的时候，自动容灾能争点气，别让我再熬一整夜。

（编辑：站长网）

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