25M请教各位专家：
我们的情况是这样的，一套RHEL 6.2 服务器上面的11.2.0.3 RAC 数据库，出现如下问题:
- 1号服务器经常自动重启，或者莫名的hang死；
- 故障时间点的OSW监控显示，CPU/MEMORY/DISK等均正常；
- 1号节点的alert日志和crsd日志里面，均看不出明显原因；
- 在crsd当中，发现了如下信息：2020-05-18 08:41:23.282: [GIPCXCPT][2775185152] gipchaInternalResolve: failed to resolve ret gipcretKeyNotFound (36), host ‘xxxxxx’, port ‘5031-eeef-1b4a-9685’
- 于是去查看了gipcd.log，发现日志一直在重复如下信息：
2020-05-18 08:44:59.776: [GIPCDMON][1029220096] gipcdMonitorCssCheck: found node xxxxxxxnode1
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorCssCheck: found node xxxxxxxnode2
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorCssCheck: updating timeout node xxxxxxxnode2
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorCssCheck: updating timeout node xxxxxxxnode2
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorFailZombieNodes: skipping live node ‘xxxxxxxnode2’, time 0 ms, endp 0000000000000000, 0000000000000920
2020-05-18 08:44:59.777: [GIPCDMON][1029220096] gipcdMonitorFailZombieNodes: skipping live node ‘xxxxxxxnode2’, time 0 ms, endp 0000000000000000, 00000000000009db
2020-05-18 08:44:59.777: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000357
2020-05-18 08:44:59.777: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000357), len(1032), buf(0x7
fab34266fa8), inf(ip: 300.300.300.5:56171, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(15), send(15), recv(15)
2020-05-18 08:44:59.778: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:00.539: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000c6d
2020-05-18 08:45:00.539: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000c6d), len(1032), buf(0x7
fab34266fa8), inf(ip: 300.300.300.5:41064, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(0), send(0), recv(0)
2020-05-18 08:45:00.539: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:02.916: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000129
2020-05-18 08:45:02.916: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000129), len(1032), buf(0x7
fab34266fa8), inf(ip: 300.300.300.5:10654, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(10), retry(0), stamp(3), send(3), recv(3)
2020-05-18 08:45:02.916: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:03.342: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 000000000000088b
2020-05-18 08:45:03.342: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(000000000000088b), len(1032), buf(0x7
fab340b3398), inf(ip: 300.300.300.5:34596, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(0), send(0), recv(0)
2020-05-18 08:45:03.342: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1) to worklist
2020-05-18 08:45:04.037: [ CLSINET][1029220096] Returning NETDATA: 1 interfaces
2020-05-18 08:45:04.037: [ CLSINET][1029220096] # 0 Interface ‘bond0’,ip=‘300.300.300.5’,mac=‘00-e0-ed-28-80-d0’,mask=‘255.255.255.0’,net=‘300.300.300.0’,use=‘cluster_int
erconnect’
2020-05-18 08:45:04.777: [GIPCDCLT][1033422592] gipcdClientThread: req from local client of type gipcdmsgtypeInterfaceMetrics, endp 0000000000000408
2020-05-18 08:45:04.778: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: Received type(gipcdmsgtypeInterfaceMetrics), endp(0000000000000408), len(1032), buf(0x7
fab340b3398), inf(ip: 300.300.300.5:32930, mask: 255.255.255.0, subnet: 300.300.300.0, mac: , ifname: ) time(0), retry(0), stamp(0), send(0), recv(0)
2020-05-18 08:45:04.778: [GIPCDCLT][1033422592] gipcdClientInterfaceMetrics: enqueue local interface metrics (1)
我一直怀疑是两个节点的私网通信有问题，但是OSW监控显示一直正常，一直到节点重启的时候才无法连通，而且也能正常ping通，ssh互连等等。
各位专家有没有谁有分析思路的？
操作系统日志上面完全就是看不出任何信息来，就像一根水管一直在正常流水，但突然就中断了，然后重启后又继续流水一样，但是就是不告诉你为什么就中断了。
补充一点：
- 私有网络采用双网卡，做bound绑定。因为gipcd进程本身就有多网卡自动冗余的工程，不知道会不会和bound产生什么冲突或者bug之类的？
评论
有用 0
先多看看数据库的各种日志吧，首先看看 ASM 日志是否有 ORA-27301、ORA-27302、ORA-27303 等的错误，因两节点 MTU 不一致会导致主机不断重启的故障。我遇到过类似的，如下文章可参考
https://www.modb.co/db/23015
评论 有用 0@JiekeXu, 这个问题我也查过，MTU配置是没有问题的。这套库以前运行一直正常，直到最近因为内存故障，更换了内存后，就开始出现这种问题。目前更换后的内存比原来的少了一半，但数据库能够正常拉起来，只是过几个钟头后1号节点就会自动重启。
恼火的是，如果是内存硬件上的故障，但是系统日志里面一点消息都没有，整个服务器的情况就像一直运行正常，然后突然间就自动重启了。请了恩墨的维保，看看他们有什么线索没有。
评论 有用 0附件是两个节点的相关日志，重点关注以下几个故障时间点：
2020年15号的凌晨4点42分左右；
2020年18号的上午9点13分左右；
2020年18号的下午14点05分左右；
以上几个时间点，都是故障时间点，其中：
第一个时间点的现象是，1号节点hang死，没有任何日志记录，直到9点多手动重启后才开始继续写日志；
第二个时间点，是在18号的早上8点40分左右手工启动1号节点CRS，运行到9点13分左右，节点被驱除然后自动重启；
第三个时间点，是在18号早上自动重启后，运行到下午大概14点05分，号节点再次自动重启。
由此可见，这个问题并非是1号节点CRS启动不正常，而是启动后，运行不了多久，短则数十分钟，长则数个小时候就会出现故障。
我觉得可以重点关注一下是否集群的gipcd进程有异常，因为1号节点在CRS运行期间一直循环报同步两个节点均超时，2号节点只是报同步1号节点超时，同步它自己2号则正常。
日志中的IP地址和hostname等信息都做了处理。
来吧兄弟们，姐妹们，都练练手吧，机会难得！
评论 有用 0补充一点：
第三个故障时间点的时候，1号节点的alert里面有报：CRS-2412:The Cluster Time Synchronization Service detects that the local time is significantly different from the mean cluster time.
这个关于两个节点时间不同步的问题，两个时间点的确存在相差大概1分钟的时间差，可能导致第三个故障时间点的发生。但是对于这个问题，我们初步也排查过，在第二个时间点之前，我们做过NTP时间同步校正，并且1号节点正常运行了1个晚上，之后我们手动关闭了1号节点的CRS以防止生产影响，然后在第二个时间点之前，手工启动了CRS以便继续诊断，结果故障依然再第二个时间点产生了。
评论 有用 0尝试清除之前的配置信息，重新执行root.sh来配置
具体步骤：
1、/opt/app/11.2.0/grid/crs/install/rootcrs.pl -deconfig
2、在/opt/app/11.2.0/grid/ 目录下执行：root.sh
评论 有用 0墨值悬赏