码迷,mamicode.com
首页 > 其他好文 > 详细

11gR2 如何诊断节点重启问题

时间:2018-08-04 12:36:15      阅读:166      评论:0      收藏:0      [点我收藏+]

标签:如何   情况下   特性   this   情况   ESS   14.   cluster   nod   

本文对如何诊断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)

 

11gR2 如何诊断节点重启问题

标签:如何   情况下   特性   this   情况   ESS   14.   cluster   nod   

原文地址:https://www.cnblogs.com/liang545621/p/9418225.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!