MySQL高可用架构实战：14年经验谈自动容灾设计

文章配图，仅供参考

　　会议室的白板没擦干净，运维小哥边画架构图边骂：“这MHA方案当初是谁拍板的？主从切换得手动触发，备库还得自己提前预热，等你们写完切换脚本，用户早跑光了！”我盯着他键盘上掉的那个“Ctrl”键——昨天还见他敲得飞起——突然想起测试环境那台Dell R740，上次模拟故障时，备库接管花了整整47秒，期间所有写操作全丢，后端接口返回500的比例直接飙到62%。

　　后来我们咬着牙上了Orchestrator，结果第一周就踩了坑：有个从库因为网络抖动被标记为“不可用”，自动隔离后，集群里只剩俩节点，这时候主库又挂了——Orchestrator直接懵了，既没触发新主选举，也没报明确错误，控制台就一行“No suitable candidate found”。我翻着那台测试机的构建日志，发现是去年12月的版本，而官方在1月就修复了“少数派集群处理逻辑”的bug，但没人注意到。外卖到了没人去拿，凉掉的炒饭在工位上摞了三层，最后还是保洁阿姨收走的。

　　现在回头看，自动容灾这玩意儿，光靠“自动”俩字根本不够。我们之前总迷信“高可用组件能搞定一切”，结果发现：MHA的切换脚本得自己维护，Orchestrator的告警规则得自己调，甚至MySQL的半同步复制参数（rpl_semi_sync_master_wait_for_slave_count）都得根据业务场景改——活动页的订单表可以接受1秒延迟，但用户余额表必须强一致，否则就会出现“扣款成功但余额没变”的鬼故事。上次测试机模拟故障，备库接管后，有个长事务卡了12秒，导致后续所有请求排队，性能面板上“Threads_running”直接从20飙到200，接口平均响应时间从80ms涨到3.2秒，首屏转圈、按钮点了没反应、控制台一片红，用户投诉像潮水一样涌进来。

　　最坑的是监控告警。我们用了Prometheus+Grafana，结果某天凌晨，磁盘空间告警和慢查询告警同时炸——前者是因为日志没轮转，后者是因为有个SQL没走索引。但告警规则是按“单个指标”触发的，没有关联分析，运维小哥被吵醒后，先处理了磁盘空间（扩容），等发现慢查询时，主库已经积压了5万条未同步的binlog。后来我们改了规则：慢查询数量超过阈值且磁盘IO超过80%时，才触发“紧急故障”告警，但测试机型号从R740换成R750xs后，磁盘IO的基准值变了，又得重新调参数——键盘上那个掉落的“Ctrl”键，到现在都没人修。

　　现在我们的方案是：主库用Percona XtraDB Cluster（PXC）搞多主同步，备库用MHA+GTID做异地容灾，监控用Prometheus+Alertmanager做关联告警，切换脚本用Ansible自动化跑。但测试时还是出过幺蛾子——PXC的“wsrep_sst_method”参数设成“xtrabackup-v2”后，第一次全量同步花了2小时，期间所有写请求都被阻塞，用户反馈“页面卡死”。后来改成“rsync”+“xtrabackup”混合模式，同步时间缩到20分钟，但备库启动后，有个表的结构和主库不一致（后端某次紧急修复没同步DDL），导致查询报错“Table doesn't exist”，控制台又炸了一波。

　　下一步打算把PXC的“wsrep_provider_options”里的“evs.keepalive_period”从5秒改成3秒，减少网络分区时的误判；再把MHA的“report_script”改成实时推送切换状态到钉钉群，而不是等运维主动查日志；最后把测试机的性能面板数据同步到生产监控，提前模拟故障场景——毕竟谁也不想再经历凌晨三点的手忙脚乱。键盘上那个“Ctrl”键，等这波上线稳定了，我亲自去行政部领个新的。

（编辑：站长网）

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