MySQL高可用架构实战：20年经验打造自动容灾方案

发布时间：2026-10-28 11:14:12 所属栏目：MySql教程来源：DaWei

导读：　　跟老板拍桌子那天是下午三点，空调直吹我后颈，我衬衫第三颗扣子刚崩开——就那声“咔”，特别清脆。他推过来一张图，说“这是新方案拓扑”，我扫了一眼，MHA + VIP漂移，底下标着“全自动容灾”。我手一松，椅子往后滑了半米，说：

　　跟老板拍桌子那天是下午三点，空调直吹我后颈，我衬衫第三颗扣子刚崩开——就那声“咔”，特别清脆。他推过来一张图，说“这是新方案拓扑”，我扫了一眼，MHA + VIP漂移，底下标着“全自动容灾”。我手一松，椅子往后滑了半米，说：这玩意儿连failover前的binlog gap都懒得校验，你管这叫自动？

　　我原以为他们会拉个会，至少搭个测试环境跑三天压测。结果PM当场在钉钉群里建了个“高可用攻坚”频道，头像换成了小火箭表情包，发了句“节奏要快，交付要稳”，然后……没人回。Lighthouse跑分截图发进去两小时，前端小张回了个“666”，后端老李转发到另一个群问“这个SSL证书是不是又得重签”，再没下文。我盯着屏幕右下角时间：十七点四十二分，办公室顶灯突然闪了一下，像接触不良的老日光灯管。

文章配图，仅供参考

　　优胜劣汰不是玄学，是血里泡出来的判断力。去年十二月雪夜，备库同步卡在position 8372145，主库写入停了七分钟，监控告警声音跟指甲刮白板似的。运维小王穿着拖鞋从工位冲出去查物理链路，我抄起终端切到GTID状态——发现是relay-log被误删后自愈失败，但MHA的check_repl_delay脚本居然还报“OK”。我当场把脚本里sleep 1改成sleep 0.1，重新打包、scp、chmod +x、systemctl restart mha-manager——这个我敢打包票，改完立刻触发降级。可主库为啥会在写满redo前主动断联？这个我说不准，现在看日志还是迷。

　　桌面那个没关的录屏软件，窗口最小化在任务栏最右，图标是红色圆点，一直跳着。我昨天把它删了三次，每次重启IDE它又自己弹出来，估计是某个插件后台挂着。倒水的是前台实习生阿哲，紫砂杯底还留着昨早枸杞渣，他接水时顺手把我桌上那叠打印纸往左挪了三厘米，歪得刚好卡进键盘缝隙。这种细节真没必要记，但我就是记得——就像记得那年用Percona XtraDB Cluster，quorum丢一个节点就集体跪，全组人围着一台物理机狂按Ctrl+C，连心跳包都懒得重传。

　　所以现在我们干的事很糙：在mysqld启动脚本里硬塞一段shell，检查/var/lib/mysql/relay-log.info是否存在且非空；存在但size为零？直接rm -f relay-log. && systemctl start mysqld；存在且size不为零？再查mysql.slave_status，如果Seconds_Behind_Master > 300，就强制跳过五个event，不等确认，不记日志。我知道有人会骂“这哪是容灾，这是裸奔”，但你去看上周生产库凌晨三点的error log，主库挂了，备库连read_only都没来得及设，就有一条insert混进去了——最后是人工比对binlog offset和pt-table-checksum结果，手动反向rollback了六万行。这事我没告诉PM，他正在折算KPI，把“自动容灾达成率”拆成“配置完成度30%+切换耗时达标率40%+无数据丢失率30%”，CDN账单倒贴了八千三，他还以为是压测流量没限住。

　　对面工程师换了一根充电线，Type-C口镀铬更亮，插拔时声音更闷。我盯了三秒，想起三年前用orchestrator做故障模拟，它能在9.3秒内完成切换——前提是所有服务器时间误差小于200毫秒，而我们产线NTP用的是默认配置，chrony.conf里没加makestep -1。后来我们干脆在每个节点启服务前先执行ntpdate pool.ntp.org，粗暴，有效，运维部至今不知道这事。有些事不是做不到精确，是做到精确的代价，比认怂贵十倍。

　　所以这套架构现在到底能不能扛住单AZ整机房掉电？我不知道。我知道它能扛住主库进程僵死、IO hang、甚至磁盘只读（靠tmpfs缓存临时表撑三分钟）。但也仅此而已。我们下周开始上Arbitrator，不为了多一层仲裁，就为了让MGR里的PRIMARY选举别再靠随机数生成器——那个函数调用栈我都背下来了，每次review PR都得手动翻两次。勾选合并请求之前，我先cd /var/log/mha，tail -n 20 manager.log，再grep “failover done”，最后才点merge，中间还要等GitLab CI跑完三个job：单元测试、SQL审核、配置校验。这三步，缺一步都不行。

　　昨晚测试环境又出幺蛾子：VIP没飘，但应用连上了旧IP，持续十九秒。查出来是ARP缓存没刷干净，运维小王蹲在交换机旁手动arp -d，我站在旁边啃冷馒头，馒头馅是韭菜鸡蛋，咬第一口的时候忽然想起，二十年前我在电信局机房也这么站着，等一根光纤熔接完。那时候没监控，没告警，只有一台带串口屏的Sun服务器，蓝屏上滚动着“waiting for master heartbeat...”，一等就是四小时。后来我把那行代码抄下来，贴在第一个工位的显示器边框上，胶布都黄了，到现在还粘着。

　　下一步？把slave_net_timeout从60秒砍到12秒。不是因为数学上合理，是因为我们实测发现，只要超过十三秒，下游业务方就开始打电话问“是不是你们接口崩了”。至于MHA那套基于SSH的检测逻辑？先让它活着。等哪天哪个兄弟真的在半夜三点被电话叫醒、摸黑爬起来敲sudo mysql -e "show slave status\\G"的时候，再说。

（编辑：站长网）

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