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

　　去年五一那会儿漏扫报告刚出来，监控室里三台显示器闪得跟迪厅似的——我原以为又是哪个开发手滑关了复制集，结果发现主库的IO线程卡了十分钟，备库的同步延迟直接飙到三万秒。当时运维小哥正蹲在机房换硬盘，门禁嘀嘀嘀响个不停，他拎着螺丝刀冲出来的时候差点撞翻咖啡机，那台旧笔记本的风扇声比打印机吐纸还吵。

　　优胜劣汰这事儿，得从我们第一代高可用架构说起。那时候图省事用MHA，脚本写得那叫一个随意，主库宕机切换全靠crontab定时检查。有次凌晨三点主库磁盘满了，MHA愣是没触发切换，备库的relay log堆到200G，等我们手动介入的时候，业务方已经把客服电话打爆了。后来查日志发现，MHA的check脚本被某个运维改成了只检查本地磁盘，而主库的日志盘是挂载的NFS——这锅甩得，连WAF日志都替我们脸红。

　　所以后来咬着牙上了Orchestrator，至少能可视化看复制拓扑。可这玩意儿也有坑，有次网络抖动导致备库短暂离线，Orchestrator直接把另一个备库提了主，结果原主库恢复后，两个库的binlog位置差了五百条。那天整改单飞得跟爬虫撞库似的，业务方在群里@我时，茶水间的灯还亮着，照得显示器反光都看不清。

文章配图，仅供参考

　　窗外的雨下了一下午，打印机还在吐纸，我盯着屏幕上的复制延迟曲线，突然想起上个月跟开发吵的那架。他们非要在主库上跑ETL，我说用Canal监听binlog走消息队列，他们说“这样太慢，影响业务”。结果呢？上周主库的undo表空间撑爆了，整个集群挂了四十分钟，等保测评的老师当时就在现场，脸色比我们的补丁版本还旧。

　　现在回头看，从单点到自动容灾，最难的从来不是选工具。是那次主备切换后，业务方发现某个报表少了两小时数据，查了半天发现是某个旧应用的连接池没配自动重连；是每次补丁更新后，总有个别节点的semaphore wait暴增，得手动杀进程重启；是上周扫描器进度条走了三小时，最后报了个“可能存在漏洞”的模糊结论，我们还得自己搭环境复现。

　　我原以为上了ProxySQL就能解决连接池问题，结果发现业务方的JDBC驱动版本五花八门，有的连failover参数都没设。后来逼着他们统一升级，开发总监在例会上拍桌子：“你们技术部就不能兼容旧版本？”我指着监控图说：“您看这连接数曲线，像不像您上次说要优化的爬虫流量？”他没说话，低头喝了口茶——那茶还是我早上泡的，都凉透了。

　　处置不到位的时候太多了。比如有次备库的myisam表没转innodb，主库切换后查询全锁表，业务中断了十二分钟；还有次GTID没开，主备数据不一致，数据修复脚本跑了整整一夜，运维小哥在机房守到天亮，出来时胡子拉碴的，像刚从黑产窝点端了服务器回来。

　　所以现在我最怕的不是工具失灵，是业务方说“这个功能先上线，安全后面再补”。上周有个新业务要赶在五一前上线，测试环境的高可用都没跑通，开发非要直接上生产。我拦着不让，业务总监说：“出问题我担着。”结果五一当天主库所在机柜的UPS故障，备库因为没做全量同步，数据丢了三小时——现在他们倒来问我“为什么没有自动恢复”，我指着整改单上的签名说：“您当时签的是‘已知风险，同意上线’。”

　　跑题说句，我们那台旧笔记本该换了，风扇声吵得我头疼。上周让行政申请采购，他们说“等保测评通过了再批”——可等保老师上次来，明明说“设备老化是潜在风险”。这逻辑，比我们某些业务的SQL还绕。

　　现在我们的架构算稳定了吗？不好说。上周扫描又报了个CVE，补丁打上去后，某个存储过程开始报错，查了半天发现是语法不兼容。运维小哥一边改代码一边嘟囔：“这比写爬虫还麻烦。”我笑了笑没说话——至少这次主备切换时，业务方没再打电话来骂人了。

　　下一步打算把Orchestrator的监控集成到钉钉群，再搞个自动化回滚脚本。不过开发说“这样会影响发布效率”，业务方说“别搞太复杂，简单能用就行”。我盯着屏幕上的复制延迟，心想：简单能用？等下次主库挂了，你们就知道“简单”俩字有多贵了。

（编辑：PHP编程网 - 钦州站长网）

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