RAC节点2遭遇连续驱逐

公司一套核心业务数据库RAC集群数据库2节点实例分别在2019年 11月13日,2020年1月2日,2020年1月11日发生3次被集群驱逐的情况发生,并且故障时,三次重启CRS均夯住,只能通过重启服务器的方式应急解决。

1.集群日志(2019.11.13)

20190112-1112.集群日志(2020.01.02)

20200112-2

3.集群日志(2020.01.11)

20200112-3

通过以上日志得知,三次实例驱逐均是因为集群间私网心跳超时导致,但是依照RAC网络心跳集群的驱逐的原则,2节点被驱逐不见得根因就是出在2节点上,该环境为2节点RAC,因心跳超时导致集群分为2个子集群,保留最小节点号的子集群会留下,所以1节点会有很大几率被保留,2节点会被驱逐。

分析Oswatcher中netstat采集的网络信息:

节点1,故障期间包重组失败统计:

20200112-04

节点1,物理丢包统计:

20200112-07

节点2,故障期间包重组失败统计:

20200112-05

节点2,物理丢包统计:

20200112-06

可以看到,节点1故障期间没有发生物理丢包与包重组失败,然而节点2则物理丢包与包重组失败都存在(数值一值在累计增加),所以基本推定节点2数据库服务器私网网卡存在异常现象。当讨论这个故障期间,有同事提出可以修改linux操作系统内核参数,避免大量包重组失败的问题:

net.ipv4.ipfrag_high_thresh = 16M     --default 4M
net.ipv4.ipfrag_low_thresh = 15M      --default 3M

这种方式是可行的,当无法排查定位出硬件设备问题时,可以尝试利用此方式来继续观察,但是上述现象除了包重组失败还存在物理丢包现象,也就是说很多Packet没有到包重组那步就已经出现ERROR于DROP的现象,物理丢包仍然会导致RAC集群心跳超时从而继续驱逐节点。

通过上述分析后,我们决定不修改内核参数,决定进行本日第二次的私网网卡切换操作,继续观察,硬件同事将eth14切换到eth08后,丢包现象消失,问题暂时解决,继续观察。