大家好我是数据库小学妹 凌晨两点十四分手机把我震醒。来电显示是监控告警接起来就听到机房值班同事的声音机房A断电UPS快撑不住了你来看下监控。我打开面板第一反应是松了口气。机房B的数据库确实提升成了主库容灾切换成功了。但这个安心只持续了三十秒。监控图上机房B的数据库CPU飙升到百分之九十五连接数爆满应用端的错误日志在疯狂滚动。所有服务都在报数据库连接超时用户端的表现是加不了购物车、付不了款、已经提交的订单卡在处理中动不了。客服群里也开始炸“大量用户投诉无法下单”“客服电话已经打不进来了”。我一边拉网络团队进群排查一边翻切换日志。从告警到切主库高可用框架用了47秒看起来很快。但从47秒之后事情就开始不对劲了。VIP漂过去了应用连不上。DNS更新了用户还在访问旧地址。两台数据库都在拒绝写入因为触发了脑裂保护。那天晚上我们折腾了将近一个小时才恢复。后来对着切换日志一行行看才意识到这套容灾方案在演练环境里跑得很漂亮到了生产环境却几乎每个环节都漏了。这篇文章我复盘了整个过程希望你们在遇到同样问题的时候能帮大家少走弯路少踩坑。概念对齐容灾的核心指标容灾这件事核心看两个指标。RPO恢复点目标意思是故障后最多丢多少数据RPO为零就是不丢数据。RTO恢复时间目标意思是故障后多久能恢复服务。这两个指标越低越好但也越贵你得根据业务重要性和预算来选。我们这次事故涉及的架构是同城双活。同一个城市两个机房各部署一套数据库通过专线同步数据延迟通常在五毫秒以内理论上RPO可以为零、RTO分钟级。架构图看着挺完美两个机房一主一备VIP做浮动地址DNS做入口调度。但真实故障从来不是按架构图来的。事故前的架构出事故之前我们的部署是这样的机房A放主库机房B放备库通过同步复制保证数据一致性。一个VIP10.0.0.100挂在主库上应用连接这个VIPDNS域名解析到这个VIP。高可用框架负责监控主库状态检测到故障后自动把VIP漂到备库同时提升备库为主。听着没毛病吧我也觉得没毛病直到那天晚上出了问题。问题一脑裂——两边都以为自己是主库机房A断电后机房B和机房A之间的网络断了。B在提升为主库之前需要确认A是真的挂了还是只是网络不通因为如果A没挂两边同时写入数据就分叉了。我们的高可用框架用了一个仲裁节点来解决这个问题当主备失联时两边都去问仲裁节点能联系上仲裁节点的那方升主另一方只读。但那天晚上仲裁节点部署在机房A。机房A断电仲裁节点也跟着挂了。机房B联系不上仲裁节点不敢升主等我们手动强制提升的时候已经过去了十分钟。事后我查文档才发现仲裁节点不能放在任何一个业务机房它必须放在第三个独立的网络环境里否则业务机房一挂仲裁跟着挂保护机制就变成了故障源。排查脑裂时的几个关键命令# 查看高可用集群状态 pcs status # PacemakerCorosync SHOW STATUS LIKE wsrep%; # Galera集群 # 查看主备复制状态 SHOW SLAVE STATUS\G # 重点关注Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master那次之后我们改了架构三个仲裁节点分布在三个不同的网络环境多数派投票两个还活着就能决策。这样任何一个机房挂了仲裁还能工作。问题二VIP漂移——漂过去了应用连不上VIP确实漂到了机房B但应用还是连不上。我查了三层原因。第一层ARP缓存没更新。交换机和路由器还记着VIP对应的旧MAC地址流量还是往机房A送。VIP漂移到新机器后新机器需要主动发送免费ARP报文来刷新网络设备的缓存但很多高可用框架默认不发或者只发一次被交换机忽略了。第二层云平台的安全组规则没跟着VIP走。VIP切过去了但安全组入站规则只绑定了旧IP流量到了机房B被拦住了。第三层机房B的防火墙入站规则没配VIP的放行规则。VIP漂过来了防火墙不认识直接丢弃。# VIP漂移后的排查步骤# 1. 确认VIP在当前机器上ipaddr show|grep10.0.0.100# 2. 发送免费ARP刷新缓存arping-Ieth0-c3-s10.0.0.10010.0.0.1# 3. 检查防火墙规则iptables-L-n|grep10.0.0.100# 4. 从应用服务器测试连通性telnet10.0.0.1003306VIP漂移只是第一步网络层的每个环节都得跟上。我们在切换脚本里加上了同步更新安全组规则和防火墙策略的步骤。问题三DNS延迟——你以为很快其实很慢VIP搞定了还有一层DNS切换。外部用户通过域名访问域名解析到VIPVIP切了DNS理论上也要更新。我们设的TTL是六十秒理论上六十秒内全球DNS缓存都会刷新。但实际情况是运营商的DNS缓存不遵守TTL可能缓存更久部分移动网络的用户半小时后还在访问机房A的旧IP。我查了下资料国内三大运营商的递归DNS服务器对TTL的遵守程度参差不齐有的会强制缓存最低十分钟。这意味着即使你把TTL设成一秒用户的请求到了运营商DNS那里照样被缓存十分钟。我们换了策略不用DNS做故障切换DNS只做全局流量调度真正的主备切换靠VIP加应用层连接池的failover机制。# 连接池多地址配置示例HikariCP jdbc:mysql://10.0.0.100:3306,10.0.0.200:3306/shop ?failOverReadOnlyfalse autoReconnecttrue connectTimeout3000 socketTimeout10000应用连接池里维护多个数据库地址主地址不可达时自动切到备地址不用等DNS刷新秒级切换。改造后的架构那次事故之后我把整套容灾架构重新设计了一遍。仲裁层三个仲裁节点分布在三个独立网络环境多数派投票决策不再依赖任何单一业务机房。网络层切换脚本自动更新安全组规则和防火墙策略VIP漂移后立即发送三次免费ARPARP超时从六十秒降到五秒。应用层连接池维护主备两个地址自动failoverDNS只做全局流量调度不参与故障切换。数据校验层切换完成后自动跑checksum对比核心表确认数据一致后再开放写入。改完之后我们又做了一轮完整的容灾演练这次不只是跑主库正常关停一种场景。容灾演练场景场景一主库进程崩溃。数据库进程意外退出但机器还在看高可用框架能不能检测到并切换。场景二主库整机断电。模拟机房断电看备库升主、VIP漂移、网络策略更新的完整链路。场景三网络分区。用iptables切断主备之间的网络看仲裁机制能不能正确判断不会两边同时升主。场景四切换中途回滚。备库升主到一半主库恢复了看系统怎么处理不会造成数据冲突。场景五数据一致性校验。切换完成后对比主备两边的数据确认没有丢失或不一致。每个场景跑完记录RPO和RTO的实际值。达不到指标的改架构、改配置、改脚本直到跑通为止。信创环境经验断电事故之后不久我参与了一个信创项目的容灾部署发现国产数据库在容灾这块有自己的一套逻辑。KES的复制协议、脑裂处理、切换流程都有一套独立的机制迁移之前必须针对KES的容灾能力做专项演练不能直接套用MySQL的经验。特别是脑裂检测的超时参数KES有自己的一套默认配置需要结合实际的机房距离、网络延迟、业务容忍度来重新评估。我在一个项目里做过KES的两地三中心部署同城双活用同步复制保证RPO为零异地灾备用异步复制做兜底。切换流程大体类似但底层参数调优的思路不同。信创项目对RPO和RTO通常有明确的合规要求政务系统一般要求RPO为零、RTO不超过三十分钟这些指标在架构设计阶段就要纳入考虑不是上线后再补的。避坑清单写几条实操中踩出来的经验供参考。演练环境不等于生产环境。演练环境的网络延迟通常很低生产环境的跨城延迟可能是几十毫秒。超时参数必须按生产环境的实际延迟来设。演练之前先在生产环境测一遍网络延迟和带宽我吃过这个亏。切换脚本要自动化别靠人工。安全组、防火墙、ARP刷新这些步骤都得写进脚本里不能靠人工临时配。凌晨两点的状态你信不过的。异常场景都要测。容灾演练不能只跑成功流程网络延迟升高、部分节点失联、切换中途回滚这些异常场景都得覆盖。只有演练里踩过的坑生产里才不会重演。切完先校验数据别急着开香槟。用checksum对比主备两边的核心表确认一致再开放写入。数据不对切得再快也是白搭。那次断电事故之后我在团队白板上写了一句话高可用架构存在的意义不是保证不出故障而是保证出了故障能快速恢复。接受故障的必然性把精力放在缩短恢复时间上比追求永不宕机靠谱得多。你现在的容灾方案真正切过一次吗如果没有找个时间窗试试吧。朋友你在容灾切换中遇到过哪些意外欢迎在评论区聊聊。我是数据库小学妹咱们下篇见