MySQL高可用架构实战：单点故障到自动容灾

　　导航突然报“前方三百米拥堵”，我猛打方向盘拐进辅路，手机支架跟着晃，差点把水杯碰倒。车厢里柴油味混着泡面味——后座那老哥在加油站买了桶红烧牛肉面，塑料叉子刮着桶壁，刺啦刺啦的。雨刷在挡风玻璃上划拉，雨不大，但总擦不干净，像极了去年一月处理MySQL故障那会儿，监控告警刷屏，怎么查都查不出根因。

　　那会儿公司数据库还是单点架构，主库挂了就得手动切备库。有天凌晨三点，主库突然宕机，我爬起来连VPN，发现备库的复制线程卡了半小时——原来是个大事务没提交，阻塞了整个复制流。切备库吧，结果备库的binlog位置比主库落后两秒，切过去后数据不一致，订单系统报了二十分钟错。老板在群里@我：“这损失够你跑半个月车了。”我盯着屏幕，手指在键盘上敲得生疼，心想这破架构早该换了。

　　后来咬牙上了MHA（Master High Availability），主库挂了就自动选新主，切换时间从半小时缩到二十秒。我原以为这下稳了，结果有次主库磁盘满了，MHA确实切了，但新主库的IO线程没跟上，复制延迟飙到五分钟。更坑的是，应用层没做重试，部分订单还是落到了旧主库（虽然它已经挂了），数据直接丢了。那天我在服务区蹲了俩小时，看运维老哥对着日志骂街，服务区那只野猫蹲在车顶，喵喵叫得像在催单。

　　现在跑的是MGR（MySQL Group Replication），三节点，强一致性，主库挂了自动选新主，复制延迟控制在毫秒级。去年双十一前，我们故意把主库杀了做演练——不是那种“提前通知所有人”的演练，是真杀，凌晨两点，监控告警炸锅，但应用层没感知到，订单量还在涨。我蹲在机房看日志，心跳快得像超速被拍——结果MGR扛住了，新主库自动接管，复制延迟始终没超过100ms。那一刻我突然懂了：高可用这玩意儿，跟跑车似的，不是看谁跑得快，是看谁摔得少。

文章配图，仅供参考

　　导航突然报“您已偏离路线”，我低头看，原来拐错了道。雨刷还在响，后座泡面味更浓了——那老哥把汤喝得一滴不剩，纸碗捏得瘪瘪的。我原以为高可用就是“不宕机”，结果发现是“宕机了也能快速恢复，而且恢复后数据没错”。就像跑车，不是永远不爆胎，是爆胎了能换胎继续跑，而且不丢客户。

　　前几天看日志，MGR集群里有个节点突然离线，自动踢出后，剩下俩节点继续服务，复制延迟还是零。我盯着屏幕笑了——这就像跑高速，一辆车抛锚了，其他车自动变道，连刹车都不用踩。老张后来找我问MGR配置，我说：“别怕麻烦，麻烦一次，省十年心。”他挠头：“那要是MGR也摔了呢？”我耸肩：“那就换更牛的架构呗，反正不能停在原地等死。”

　　服务区那只野猫又来了，蹲在车头，眼睛亮得像监控告警灯。我摇下车窗，它喵了一声，转身跑了。雨刷停了，雨也小了，导航重新规划了路线，显示“预计到达时间比原计划晚十分钟”。我踩油门，心想：晚十分钟就晚十分钟，总比摔在半路强。

（编辑：站长网）

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