因为diagwait未配置导致RAC脑裂日志记录不完整的分析案例

1、故障现象

    一个RAC，CRS版本为10.2.0.4，在第二节点DOWN机后，第一节点也相继DOWN机。

2、CRS日志分析

2.1 二节点日志情况

CRS_LOG

[cssd(8796)]CRS-1611:node XXdb1 (1) at 75% heartbeat fatal, eviction in 14.118 seconds 2014-07-04 22:49:38.556 [cssd(8796)]CRS-1611:node XXdb1 (1) at 75% heartbeat fatal, eviction in 13.128 seconds 2014-07-04 22:49:46.561 [cssd(8796)]CRS-1610:node XXdb1 (1) at 90% heartbeat fatal, eviction in 5.128 seconds 2014-07-05 03:00:08.142 [cssd(8812)]CRS-1605:CSSD voting file is online: /dev/raw/raw18. Details in /home/oracle/product/10.2.0/crs/log/XXdb2/cssd/ocssd.log.

从2014-07-04 22:49:46.561直接跳到03:00:08.142  ，中间没有了其它记录，实际上集群发生分裂的日志并没有写完整，如节点驱促信息，与集群重构信息

2.2 一节点日志情况

2014-07-04 23:00:00.018 [cssd(27561)]CRS-1612:node XXdb2 (2) at 50% heartbeat fatal, eviction in 29.144 seconds 2014-07-04 23:00:15.017 [cssd(27561)]CRS-1611:node XXdb2 (2) at 75% heartbeat fatal, eviction in 14.144 seconds 2014-07-04 23:00:24.014 [cssd(27561)]CRS-1610:node XXdb2 (2) at 90% heartbeat fatal, eviction in 5.144 seconds 2014-07-04 23:00:25.016 [cssd(27561)]CRS-1610:node XXdb2 (2) at 90% heartbeat fatal, eviction in 4.144 seconds 2014-07-05 01:21:06.620 [cssd(31191)]CRS-1605:CSSD voting file is online: /dev/raw/raw18. Details in /home/oracle/product/10.2.0/crs/log/XXdb1/cssd/ocssd.log.

       从2014-07-04 23:00:25.016直接跳到01:21:06.620  ，中间没有了其它记录，实际上集群发生分裂的日志并没有写完整，如节点驱促信息，与集群重构信息

2.3 问题小结

       两个节点的重启日志都没有写完整就发生了操作系统的重启，二节点的驱促信息都没有来得及发送到一节点，致使一节点并不知道二节点已经消失，然后一节点也去通过心跳线ping二节点，发现与二节点心跳存在异常，一节点重启原因由于缺少操作系统性能监控数据支持（如服务器当时负载是否很高）以及日志的不完整难以断定重启的真正原因。

3、正常日志应有情况

2014-06-24 14:53:21.258 [crsd(8825)]CRS-5504:Node down event reported for node 'tsrrac02'. 2014-06-24 14:53:21.259 [crsd(8825)]CRS-2773:Server 'tsrrac02' has been removed from pool 'ora.crmout'. 2014-06-24 14:53:21.259 [crsd(8825)]CRS-2773:Server 'tsrrac02' has been removed from pool 'Generic'.

4、CRS配置情况检查

$ crsctl get css diagwait  Configuration parameter diagwait is not defined.

问题：两个节点配置相同，对diagwait均未配置

5、对diagwait未配置默认值与问题风险的官方说明

Using Diagwait as a diagnostic to get more information for diagnosing Oracle Clusterware Node evictions ( Doc ID 559365.1 )  《==This setting will provide more time for diagnostic data to be collected by safely and will NOT increase probability of corruption.  OPROCD 是用来检查节点是否hang的，当它发现节点hang后，会发起起点重启。  它有两个重要的参数：  oprocd.debug -t 1000 -m 500  timeout value (-t <to-millisec>) ：每次执行检查的间隔，默认为1000ms(1s).  margin (-m <margin-millisec>) ：允许延迟的时间，默认为500ms(0.5s))  OPROCD 进程每隔to-millisec（1s）进行一次检查，检查的时候会获取OS的时间，然后用这个时间减去上次获取的OS的时间，如果这个时间差大于to- millisec + margin-millisec，那么OPROCD会认为OS hang了，就会发起重启。简单说来，如果不改变上面两个参数的值，那么默认情况下，如果OPROCD在1.5s都无法获取到OS的时间，就认为OS hang了。    修改了diagwait为13s后，会把margin-millisec设为10s，也就是允许获取OS的时间达到11s(1s+10s).

6、改进方案

    该问题只会出现在ORACLE 11.2以前版本中，在 11G R2版本中，diagwait的值默认配置为13   

    针对11.2以前的版本，需要手工将diagwait修改为13，以推迟重启的时间便于将缓存中的日志信息有足够的时间写入到磁盘文件中，以及减少因为与OS交互允许时间太短而造成的重启可能。

 

 

本文作者：黎俊杰（网名：踩点），从事”系统架构、操作系统、存储设备、数据库、中间件、应用程序“六个层面系统性的性能优化工作

欢迎加入 系统性能优化专业群，共同探讨性能优化技术。群号：258187244