故障处理：Oracle ADG中VIP地址切换到新主库时网络不通的故障处理

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

在这篇文章文章中，我们提到某三甲医院HIS核心系统采用Oracle单机+ADG的架构。最近因为要扩容本地SSD硬盘，需要在中午做数据库ADG切换。整个切换对时间要求非常严格，预计是5分钟正常切换完成，预留5分钟故障处理，预留5分钟回切，整个ADG切换业务RTO计划为5分钟，最大为15分钟，预估为3分钟。由于时间的严格要求，所以切换过程中尽量采用并行的操作进行，就是因为并行的操作，后面出现诡异的现象：VIP地址切换到新主库后出现大约2分钟左右的VIP地址网络不通，此现象在过去多次切换中从未遇到过。

故障临时解决

在7年前的方案设计验证、系统上线前的演练、系统上线后故障切换这三个阶段中，经历了正常的ADG切换、异常ADG切换，总切换次数不少于10次，从未遇到过这次的故障，有点怀疑是不是操作系统BUG导致。由于时间太短无法去做故障分析，所以临时想了一个解决方案，既然ip add添加IP地址不行，那就将VIP地址改为网卡的固定IP地址。经过和客户的网络工程师、DBA简单沟通后，大家立马达成共识，我三下五除二，执行下面的命令，切换IP地址。

sed -i 's/999.999.999.999/888.888.888.888/' /etc/sysconfig/network-scripts/ifcfg-eth3 
/etc/init.d/network restart

重启完网卡后，网络工程师立马说通了。心里面一万匹马飘过，难道真的遇到Linux的BUG了。在场的所有人一脸懵逼，此时我站起来说了一句，是不是因为MAC地址没有更新导致的。

分析和验证过程

完成上面整个过程只用了几分钟的时间，一看时间，离15分钟还有几分钟的时间，跟网络工程师商量了一下，要不要我们再将IP地址切换回来，看看VIP地址是否还能通。再有限的时间内去寻找规律和变化，争取能找到故障点。不到3句话大家达成共识，再给领导汇报一下，领导问能否在15分钟恢复业务，在给予肯定回答后，领导直接让你们切换吧，这个问题如果找不到原因，以后故障时间点出现问题会更麻烦，领导还是领导，有前瞻性眼光，看事情看得更远。

再次切换IP地址，故障重现

通过相同的方式演练一次，现象还是存在。但是这次有一个收获，在持续的ping地址过程中发现，大概2~3分钟后VIP地址就可以ping通了，先是同网段先ping通，后是跨网段也能ping通了。这里我更加坚定可能是遇到MAC地址缓存过期的BUG了。这里为什么说是BUG呢？因为方案演练了10次以上，之前都没有遇到过，这次遇到，应该是BUG的原因。

通过这次的故障重新让我们获得需要2~3分钟后能通的重要信息，同时整个变更的时间窗口也要结束，所以就通知业务人员，检查业务或者恢复业务的运行。

分析本次切换与之前操作的差异

事后自己独自分析时，去查询几年前的CRT历史日志操作记录，发现一个诡异的现象，每次的ADG切换时间相差不多，但是本次VIP地址从老生产环境切换到新生产环境的时间从原来的几分钟变到了这次的1分钟，并且IP地址操作的顺序也不一样。历史操作记录是ADG切换完成后，确认新主从关系的ADG同步正常后才将VIP地址通过ip add命令添加到新主库，然而这次由于是在中午时间，对时间要求严格，所以就在ADG切换完成后立马将VIP地址添加到新主库，整个过程用时不到2分钟。哎，在IT运维上，有些时候操作太快、时间太短也不一定是好事情。

通过搜索的力量

虽然大学就考过网络四级工程师，但是拿到这种BUG问题，确实没有太多的经验，感觉无从下手。正面无从下手，就侧面下手。这个时候我想到如果是BUG，那么其他的VIP切换工具一样会遇到这个问题，在Linux下keepalived这个工具就是专门用于做VIP地址切换的，所以在Google里面通过如下的关键词搜索"keepalived VIP switch unreachable"，结果如下：
搜索结果

通过1348929 – keepalived VIP becomes unreachable after这个链接，可以发现现象一模一样，其中页面有如下的信息：

(In reply to andrea from comment #0)
> Description of problem:
> 
> In a 2 nodes keepalived cluster, (probably for a network problem) when a
> backup node becomes master and sends the gratuitous arp and right after it
> receive an higher prio advert falling back as backup, it releases the VIP,
> however the master node doesn't sends gratuitous arp causing a L3 problem
> resulting in VIP unreachable from outside the network.

Can you show that the new master is not sending the gratuitous arp? The logs you provided do not show a problem.

> on http://www.keepalived.org/changelog.html release 1.2.22 seems to solve
> similar issues

Can you please be specific? Which entry in the changelog seems to solve this problem? Just to be clear, this behavior is occurring on RHEL7.2 with keepalived-1.2.13-7.el7.x86_64, correct? Is there a support case open for this issue? Have you attempted to use garp_master_delay or garp_master_refresh?

这里提到gratuitous arp，跟前面说到的MAC地址缓存有关系了。
于是再通过Google和AI，搜索gratuitous arp的信息，在了解了基本信息以后，再用gratuitous arp vip switch等关键词搜索信息，基本上就找到了问题的原因。

问题原因

在操作系统、网络设备中，同网段的通信是通过MAC缓存表来快速实现IP地址与MAC地址的转换的。在VIP地址从一台服务器切换到另外一台服务器时，操作系统不会主动触发MAC地址缓存表刷新，此时VIP在缓存中还对应原来的服务器，所以此时会出现短暂的IP地址不通的现象。

解决方案

手动广播IP地址的MAC地址

arping -U -c 3 -I eth0 -s 192.168.1.101

配置操作系统缓存表过期时间

由于配置操作系统影响比较大，所以暂时不采用这种方式。

总结与最佳实践建议

技术专家视角的深度思考

网络协议层面的认知升级
- 任何的最佳实践都可能存在不足，最佳实践来源于经验的累积，但不要过度迷恋最佳实践
- VIP切换不仅仅是应用层面的操作，更是网络协议栈各层协同工作的系统工程
- ARP缓存、MAC地址表、路由表等网络组件的状态一致性是VIP切换成功的关键
故障排查方法论
- 变通的知识探索方式：有很多知识我们可能没有深入接触过，但可以通过类比或相似方式来思考
- 结合Google和AI的搜索结果，往往能出现柳暗花明，找到问题的答案
- 从现象到本质的逆向思维：通过已知的相似问题（如keepalived）来推断未知问题的根本原因
系统架构设计的反思
- 高可用架构全面性：不仅要考虑应用层面的切换，更要考虑网络层面的协同
- 时间窗口的合理规划：RTO目标设定要预留足够的网络协议收敛时间
- 并行操作的风险评估：看似提高效率的并行操作可能引入新的依赖关系问题
技术能力的提升

能力的全面性：对数据库运维人员的能力要求不仅仅需要大家成为一个数据库专家，也要求对整个IT的知识点都需要全面的了解，才能应对在当前越来越复杂的IT环境中解决真实的问题。
主动意识的提升：在服务过程中，对主动意识要求越来越高。需要有主动的意识，主动帮助客户以解决客户问题为目标来贡献自己的力量，哪怕微弱的力量，也有可能帮助客户提供一个新的思路，加速故障解决的速度。

客户需要重点考虑的关键要素

业务连续性保障
- RTO目标的合理性：5分钟的RTO目标在技术上可行，但需要充分考虑网络协议收敛时间
- 故障回切策略：不仅要考虑正常切换路径，更要设计异常情况下的快速回切机制
- 业务影响评估：VIP不通的2-3分钟对业务系统的影响程度和可接受性
技术风险管控
- 变更窗口选择：中午业务高峰期进行架构变更的风险评估和应急预案
- 技术债务识别：历史演练中未发现的问题可能成为生产环境的潜在风险点
- 专家资源储备：关键变更时需要有足够的技术专家在现场进行决策和应急处理
运维能力建设
- 故障处理流程：建立标准化的故障处理流程，包括临时解决方案和根本解决方案
- 知识库建设：将本次故障的处理经验和解决方案纳入知识库，避免重复踩坑
- 团队协作机制：网络工程师、DBA、系统工程师之间的协作机制和沟通流程

行业最佳实践建议

医疗行业特殊考虑
- 合规性要求：HIS系统的变更需要符合医疗行业的相关法规和标准
- 业务影响最小化：医疗系统的可用性直接关系到患者安全，变更风险控制尤为重要
- 监管报告机制：重大变更后的效果评估和监管报告要求
技术架构演进
- 自动化运维：通过自动化工具减少人工操作失误和提升故障处理效率
- 监控告警体系：建立完善的网络层面和应用层面的监控告警体系
长期规划建议
- 技术栈标准化：统一VIP切换工具和流程，避免不同方案带来的不一致性
- 容灾能力提升：从单数据中心向多数据中心容灾架构演进
- 运维团队能力建设：定期进行技术培训和故障演练，提升团队整体技术水平

通过这次故障处理，深刻认识到高可用架构的复杂性不仅在于应用层面的设计，更在于网络协议栈各层之间的协同工作。对于客户而言，需要在技术先进性和业务稳定性之间找到平衡点，建立完善的变更管理和风险控制机制。

——————作者介绍———————–
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)