原文链接:https://blogs.oracle.com/database4cn/11gr2
本文对如何诊断11gR2 GI环境下的节点重启问题进行了一些介绍。
首先,像10g版本一样,我们首先介绍在GI中能够导致节点重启的进程。
1.Ocssd.bin:这个进程的功能和10g版本的功能基本差不多,主要是节点监控(Node Monitoring)和组管理(Group Management)。详细的信息请参考之前文章“如何诊断节点重启问题”了解详细的内容。
2.Cssdagent.bin/Cssdmonitor.bin:这2个进程是11gR2新增加的。他们的工作主要是同ocssd.bin进行本地心跳(Local HeartBeat),默认情况下每1秒钟一次。本地心跳的作用是监控本地的ocssd.bin进程是否正常运行。同时,他们也监控自己到ocssd.bin之间的连接。所以,我们可以认为,这两个进程的出现代替了10g中的oclsomon/oclsvmon(如果第三方集群管理软件存在)和oprocd。
接下来,介绍一个11gR2的重要的新特性—rebootless restart,这个新特性是在版本11.2.0.2被介绍的。从这个版本开始,当集群中的某个节点被驱逐(例如丢失网络心跳)或者该节点的ocssd.bin出现问题时,集群将不会直接重新启动该节点,而是首先尝试重新启动GI stack来解决问题,如果GI stack不能够在指定的时间内(short disk I/O timeout)完成graceful shutdown,才会重新启动节点,之后,存活的节点对集群进行重新配置。
下面我们列出在诊断11gR2 节点重启问题时经常搜集的信息
1.Ocssd.log
2.Cssdagent 和 cssdmonitor logs
<GI_home>/log/<node_name>/agent/ohasd/oracssdagent_root/oracssdagent_root.log
<GI_home>/log/<node_name>/agent/ohasd/oracssdmonitor_root_root/oracssdmonitor_root.log
3.Cluster alert log
<GI_home>/log/<node_name>/alert<node_name>.log
4.OS log
5.OSW 或者 CHM 报告
最后,我们对常见的节点重启的问题进行介绍。
1.由于丢失网络心跳导致的节点重启问题。对于这种原因导致的节点重启,诊断的方式和10g基本没有什么区别。但是有一个误区需要指出来。下面是一段GI alert log 信息,他们来自于node2。
2012-08-15 16:30:06.554 [cssd(11011) ]CRS-1612:Network communication with node node1 (1) missing for 50% of timeout interval. Removal of this node from cluster in 14.510 seconds
2012-08-15 16:30:13.586 [cssd(11011) ]CRS-1611:Network communication with node node1 (1) missing for 75% of timeout interval. Removal of this node from cluster in 7.470 seconds
2012-08-15 16:30:18.606 [cssd(11011) ]CRS-1610:Network communication with node node1 (1) missing for 90% of timeout interval. Removal of this node from cluster in 2.450 seconds
2012-08-15 16:30:21.073 [cssd(11011) ]CRS-1632:Node node1 is being removed from the cluster in cluster incarnation 236379832
2012-08-15 16:30:21.086 [cssd(11011) ]CRS-1601:CSSD Reconfiguration complete. Active nodes are node2 .
以上的信息并不一定说明节点node1是由于丢失网络心跳而被驱逐出集群的,首先我们要验证, node2在报 node1 丢失网络心跳的时候node1 的状态,如果说node1 已经重启或者存在严重的性能问题(可以通过os log 或者OSW 报告验证),那么node1 重启并不是由于node2发现node1丢失网络心跳造成的,而是由于node1出现问题后产生的结果,这里的reconfiguration,仅仅是集群成员信息的更新,并不会导致节点重启。而且,从11.2.0.2开始,由于rebootless restart的介入,node eviction 首先导致的结果是GI stack重启,而不是直接节点重启。但是,如果在node2报node1丢失节点心跳的时候,node1的ocssd.bin仍然正常运行(可以通过ocssd.log验证)或者node1也报丢失了和其他节点的网络心跳,那么node1的重启是由于GI node eviction导致的。
2.由于丢失磁盘心跳导致的节点重启,这种情况和10g的情况基本相同,在这里不作详细的描述。
3.由于ocssd.bin 丢失了和Cssdagent/Cssdmonitor.bin的本地心跳导致的节点重启,对于这种情况,一般来说,我们会在oracssdagent_root.log 或oracssdmonitor_root.log 看到以下的信息。
2012-07-23 14:09:58.506: [ USRTHRD][1095805248] (:CLSN00111: )clsnproc_needreboot: Impending reboot at 75% of limit 28030; disk timeout 28030, network timeout 26380, last heartbeat from CSSD at epoch seconds 1343023777.410, 21091 milliseconds ago based on invariant clock 269251595; now polling at 100 ms
……
2012-07-23 14:10:02.704: [ USRTHRD][1095805248] (:CLSN00111: )clsnproc_needreboot: Impending reboot at 90% of limit 28030; disk timeout 28030, network timeout 26380, last heartbeat from CSSD at epoch seconds 1343023777.410, 25291 milliseconds ago based on invariant clock 269251595; now polling at 100 ms
……
从上面的信息我们看到本地心跳的timeout时间为28 秒左右(misscount – reboot time)。
4.由于操作系统资源竞争导致的节点重启。 如果说操作系统的资源被耗尽或者存在严重的竞争,也会导致ocssd.bin不能正常工作,造成节点重启。对于这种情况,虽然重启操作系统的命令会由ocssd.bin发出,但是真正的原因是os资源竞争。以下是一小段OSW输出,它显示了 在节点重启之前 cpu 耗尽。
Linux OSWbb v5.0 node1
SNAP_INTERVAL 30
CPU_COUNT 8
OSWBB_ARCHIVE_DEST /osw/archive
procs ———–memory———- —swap– —–io—- -system– —–cpu——
r b swpd free buff cache si so bi bo in cs us sy id wa
……
zzz ***Mon Aug 30 17:55:21 CST 2012
158 6 4200956 923940 7664 19088464 0 0 1296 3574 11153 231579 0 100 0 0 0
zzz ***Mon Aug 30 17:55:53 CST 2012
135 4 4200956 923760 7812 19089344 0 0 4 45 570 14563 0 100 0 0 0
zzz ***Mon Aug 30 17:56:53 CST 2012
126 2 4200956 923784 8396 19083620 0 0 196 1121 651 15941 2 98 0 0 0
对于这种原因导致的重启问题,也适用于10g。
本文只是对11gR2诊断节点重启问题进行了简单的介绍,更详细的内容,请参考以下的内容
Note 1050693.1 : Troubleshooting 11.2 Clusterware Node Evictions (Reboots)
最新评论
这个牛
放下欲望,男人从来不醉,充分且必要
勇气、责任、自信、创新,为天下先!
软件即数据,软件即服务,软件即管理,软件就是对人类各种社会活动的仿真和记录。软件很重要,但软件不可能凌驾于业务之上,尤其不可能高人一等。