2节点RAC数据库只能任一启动一个 – 故障小计

关键词

oracle 12.2 rac rp_filter

No reconfig messages from other instances

LMON is terminating the instanc

Pending Sends: Yes Unacked Sends: Yes

startup: ORA-03113: end-of-file on communication channel

前言

前面安装的2套12.2的集群，主库正常使用了2周，今天给另一套做备库的集群搭建standby启动2个备库instance出现问题，2节点的rac其中一个始终无法启动，但是测试2个关闭后启动任意一个，都是可以正常启动的，再启动另一个就不行，因此判断db应该是没问题的，初步判断是网络问题导致instance通讯故障导致其中1个节点无法加入cluster。（加上甲方说前几天刚改过网络路由，于是自己更加相信是网路问题，同样2个集群4个服务器一起提供的资源，为啥主库没问题，更觉得是网络问题）

环境

操作系统	redhat 7.6
内核版本	3.10.0-1062.9.1.el7.x86_64
GI版本	12.2.0.1
节点数	2节点
database_role	PHYSICAL STANDBY
pub ip	每节点1个（2个网卡bounding为1个ip）
vip ip	每节点1个
scan ip	使用1个
priv ip	每节点2个（eth2、eth12 注意:未bound，直接使用集群自己负载均衡）

集群环境安装请参考之前博文（redhat7.6 安装 oracle 12.2.0.1 RAC 小计）

故障分析

1 2	-- 创建standby： duplicate ... 略

修改参数文件，主要是cluster_database、instance_number、undo等改成rac数据库，然后关闭存活节点，同时启动2节点：
-- 启动 DB，开始报错
srvctl start database -d orcldg
---------------------------------------------------------
PRCR-1079 : Failed to start resource ora.orcldg.db
CRS-5017: The resource action "ora.orcldg.db start" encountered the following error:
ORA-03113: end-of-file on communication channel
Process ID: 0
Session ID: 0 Serial number: 0
---------------------------------------------------------

查看db alert日志

-- 这是错误节点日志，正常节点alert无任何异常（请忽略时间）
Starting background process MARK
2017-04-18T13:12:14.468472-04:00
MARK started with pid=61, OS id=6843
2017-04-18T13:12:14.522134-04:00
NOTE: MARK has subscribed
2017-04-18T13:12:15.938855-04:00
Using default pga_aggregate_limit of 7680 MB

-- <<<注意，pga内存输出后开始报错，无法正常nomount
Instance termination initiated by instance 1 with reason 1.
Instance 1 received a reconfig event from its cluster manager indicating that this instance is supposed to be down
Please check instance 1 alert log and LMON trace file for more details.
Please also examine the CSS log files.
LMON (ospid: 6725): terminating the instance due to error 481
2017-04-18T13:16:49.129748-04:00
System state dump requested by (instance=2, osid=6725 (LMON)), summary=[abnormal instance termination].
System State dumped to trace file /orabase/diag/rdbms/xxxxx/xxxxx/trace/xxxxxx_diag_6673_20170418131649.trc
2017-04-18T13:16:49.391105-04:00
Dumping diagnostic data in directory=[cdmp_20170418131649], requested by (instance=2, osid=6725 (LMON)), summary=[abnormal instance termination].
2017-04-18T13:16:50.535863-04:00
Instance terminated by LMON, pid = 6725

-- 提示我们查询lmon和diag日志

查看diag日志

里面是问题节点 system dump，未发现明显异常，看到很多rpc等待和db关键process都为dead。

查看lmon日志

问题节点最新lmon显示未收到reconfig信息，所以通过vot磁盘收到kill请求，被踢出无法正常启动。

No reconfig messages from other instances in the cluster during startup. Hence, LMON is terminating the instance. Please check the network logs of this instance as well as the network health of the cluster for problems

正常节点最新lmon日志，显示这个runing的节点向刚刚后面启动的故障节点发送reconfig信息的时候packge信息被delete了, route outstand … (其中发现奇怪的是，2个节点priv使用的eth2和eth12，asm和db启动alert中也明确显示使用了2个相应的169的haip，但是这里报错 Local Address: :64828 Remote Address: :50737 –> 也就是说2个priv ip的haip地址交互交叉了，本地的eth2的64828端口和eth12的50737端口交互，但不通（其实这里就是重点，只不过我未发现当时）

kjxgrssvote_check_conn_i: reqid 1, check-only no, timeout in 38 sec
kjxgrssvote_check_conn_i: netcheck inst map: 1 2
IPCLW:[0.0]{E}[WAIT]:PROTO: [343641687000]ACNH 0000023320A3FA68: 16 attempts to connect:
IPCLW:[0.1]{-}[WAIT]:UTIL: [343641687000] ACNH 0000023320A3FA68 State: 0 MSN: 8841 Seq: 32400 # Pending: 2
IPCLW:[0.2]{-}[WAIT]:UTIL: [343641687000] Peer: [UNKNWN].0 AckSeq: 0
IPCLW:[0.3]{-}[WAIT]:UTIL: [343641687000] Flags: 0x00000000 IHint: 0x2e590000001f THint: 0x0
IPCLW:[0.4]{-}[WAIT]:UTIL: [343641687000] Local Address: <privateIP_node2>:64828 Remote Address: <privateIP_node1>:50737
IPCLW:[0.5]{-}[WAIT]:UTIL: [343641687000] Remote PID: ver 0 flags 1 trans 2 tos 0 opts 0 xdata3 a9c5 xdata2 afd6b420
IPCLW:[0.6]{-}[WAIT]:UTIL: [343641687000] : mmsz 32768 mmr 4096 mms 4096 xdata 4f7d10
IPCLW:[0.7]{-}[WAIT]:UTIL: [343641687000] IVPort: 6259 TVPort: 32016 IMPT: 15357 RMPT: 43461 Pending Sends: Yes Unacked Sends: Yes
IPCLW:[0.8]{-}[WAIT]:UTIL: [343641687000] Send Engine Queued: No sshdl -1 ssts 0 rtts 0 snderrchk 0 creqcnt 16
IPCLW:[0.9]{-}[WAIT]:UTIL: [343641687000] Unackd Messages 8839 -> 8840. SSEQ 32398 Send Time: INVALID TIME SMSN # Xmits: 0 EMSN INVALID TIME
IPCLW:[0.10]{-}[WAIT]:UTIL: [343641687000] Pending send queue:

查看crs日志

问题节点$GRID_BASE/diag/crs…/trace/alert日志显示 ora.orcldg.db 资源有问题，无法启动：（也无明显问题能定位原因）

[Thread-1270] [ 2017-04-18 13:16:57.125 EDT ] [CRSNative.genericStartResource:569] CRS-5017: The resource action "ora.orcldg.db start" encountered the following error:
ORA-03113: end-of-file on communication channel
Process ID: 0
Session ID: 0 Serial number: 0
. For details refer to "(:CLSN00107:)" in "/orabase/diag/crs/xxxxxx/crs/trace/crsd_oraagent_oracle.trc".

CRS-2674: Start of 'ora.orcldg.db' on 'node01' failed
CRS-2632: There are no more servers to try to place resource 'ora.orcldg.db' on that would satisfy its placement policy
oracle.cluster.impl.crs.cops.CRSNativeResult.createException(CRSNativeResult.java:617)
oracle.cluster.impl.crs.cops.CRSNative.doStartResource(Native Method)

手动检查网络

ping 对端 pub ip、vip、2个priv ip都是正常的，这也不奇怪，如果集群层面出现网络问题的话，集群层面的网络心跳故障，早就会有集群节点故障或者导致某个节点cluster被重启了，甚者重启节点。

cluvfy验证：cluvfy comp nodereach/nodecon/clu 几个命令校验了集群网络，完整性，除了resolve.conf告警，因为集群安装使用的是 /etc/hosts配置的ip解析可以忽略，所以都是正常的。

到这里我觉得是 2个priv ip的虚拟ip 169.254.xxx.xxx，oracle这2个haip出问题了，2个priv的物理网卡192.168的地址应该是正常的，否则集群应该是不正常的，现在只有db实例不正常。

谷歌和mos发现和我情况一样文章 (Doc ID 2528588.1) ，也是12.2 rac其中一节点无法启动，故障现象和报错都一致，文中说明是dbca建新库或是老库修改过网络导致2个节点无法同时启动，请检查priv网络和防火墙，没有具体说明如何排错网络。（其实oracle dba本来就还挺难的，服务器、网络、存储都需要涉及了解一些，后面又发现一篇文章，大佬就是自己tcpdump抓包确定网络问题，然后对比不同服务器操作系统正常和异常的内核参数值发现rp_filter参数值导致网络问题的）

》》》

当时我到这里就卡住了，想着要不把haip禁用，直接使用priv ip作为集群互联。这虽然能解决问题，但是未发现本次故障根因。

想着虽是客户standby，但也是生产环境，秉着严谨态度，想找出为什么2个haip会有问题，而主库集群也是一样配置，确实正常的。

》》》

幸运的是今天有位原厂oracle大佬帮忙一起排查，在他指导下顺利发现了问题，如下：

-- 测试1.显示设置DB参数 cluster_interconnects
alter system set cluster_interconnects='192.168.4.1' sid='orcl1' scope =spfile;
alter system set cluster_interconnects='192.168.4.2' sid='orcl2' scope =spfile;

-- 测试2.显示设置DB参数 cluster_interconnects
alter system set cluster_interconnects='192.168.5.1' sid='orcl1' scope =spfile;
alter system set cluster_interconnects='192.168.5.2' sid='orcl2' scope =spfile;

-- 测试2.显示设置DB参数 cluster_interconnects
alter system set cluster_interconnects='192.168.4.1:192.168.5.1' sid='orcl1' scope =spfile;
alter system set cluster_interconnects='192.168.5.2' sid='orcl2' scope =spfile;

-- 上面测试指定的ip使用4.x/5.x对应的169.254的haip也是一样的，因为都是priv网卡的虚拟ip
测试1、2都是成功的，2个节点DB实例正常都可以启动，测试3失败，node1配置4.1、5.1和node2只配置5.2网络错位了，果然后面一个node无法启动成功，这时没在往下测试了，发现好像网络错位确实不行。

-- 于是在主库和standby库指定ping对比：
ping  -I  192.168.4.1  192.168.4.2        -- 这显然可以
ping  -I  192.168.4.1  192.168.5.2        -- 正常的主库集群可以，这次故障的备库集群不行（就是从4.x网络无法ping通另一不同网段的5.x网段ip）

最后终于发现问题，主库集群和备库集群同是相同硬件和rhel7.6系统资源，但是主库是模板安装，备库是手工配置的，所以内核参数sysctl.conf中未修改rp_filter参数，导致默认参数会对网络数据包源地址进行严格校验，所以备库上面那个：ping -I 网络不通，在网络层面就是不通，在DB层面就是新启动节点的reconfig信息无法从reconfig master节点收到，导致后面的db instance无法启动。

解决

# 修改或者添加 standby 集群2节点内核参数并使之生效：
vim /etc/sysctl.conf # 或者 /etc/sysctl.d/98-oracle.conf

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.eth2.rp_filter=0        # eth2为第1个priv 网卡接口（按需修改）
net.ipv4.conf.eth12.rp_filter=0        # eth12为第2个priv 网卡接口（按需修改）

# 生效
sysctl -p

然后再次测试之前ping -I 地址已经成功ping通，将之前测试的DB参数cluster_interconnects进行reset还原，重启2个instance，都正常启动。

结语

rp_filter参数控制系统网络包响应返回路劲检查：0为不检查，1为检查，2为宽松模式，oracle推荐为2，一般设置成0或者2应该都行。

后面检查11g发现，11g使用2个priv ip来负载均衡内网不需要配置rp_filter也是可以的，即上面测试ping -I 从priv网卡1到节点2网卡2不通2节点DB也是正常的。可能是12c的DB的内网交互网络这块不同，asm也是同时使用2个haip不配置rp_filter参数也是正常都启动的，估计就DB的消息交互可能会网卡错开，导致校验错误，Linux 6和7默认都是1，启用校验。

反思：

这个参数单实例、或者rac使用单个priv ip，或者多个priv ip bounding后应该不配置也都不影响（oracle现在priv自己负载均衡，不需要priv 聚合，pub使用聚合），但这次恰好甲方环境严格，资源至少都是2路冗余的，导致未能及时发现问题。另外就是自己也大意，对于新装的环境，新建的库，以为都是统一一样的模板自动化安装配置，服务器环境应该是一致的，加上网络改过路由，就没想到去校验一下主机参数配置。

所以还是要严格安装规范来，很多时候觉得安装个库很简单，但由于不规范，比如参数或者资源限制修改不到位，莫名其妙出问题，db和crs的alert提示不太具体明确，没有遇到过没经验的话还是很难一下发现定位到问题。（另外关于rac的架构和知识也要多学习掌握，比如资源启动和管理，crs和db的几种心跳，cluster_interconnects…参数使用）

当时没定位到rp_filter参数问题前，仅靠db和crs alert日志信息还是很难在谷歌和mos找到具体问题和答案，所以除了掌握基础知识，提高问题解决能力外，积累经验还是非常重要啊，哈哈 ^_^

参考文章

mos文章：Only One Instance of a RAC Database Can Start at a Time: Second Instance Fails to Start due to “No reconfig messages from other instances” - LMON is terminating the instance (Doc ID 2528588.1)
mos文章：DBCA Second/last instance startup fails/ generic startup with ORA-03113 in 12.2 due to wrong rp_filter setting for private interconnect interfaces (Doc ID 2260078.1)
mos文章：rp_filter for multiple private interconnects OL7 (Doc ID 2216652.1)
ITPUB文章：老司机遇到的ORACLE 12C安装问题
rp_filter内核参数介绍
cluster_interconnects使用
18c官方文档说明：Multiple Private Interconnects and Oracle Linux

自律自由

2节点RAC数据库只能任一启动一个 -- 故障小计