author：skate
time：2012/07/16
无意中发现以前处理故障写的一篇文章，记录下来以备查找。
rac集群节点级联重启故障分析
环境：
os：linux
db：rac10g+ocfs2
rac数据库环境实际包含两个集群，一个是clusterware集群，一个是instance集群。他们的大概工作方式是：
1.如果clusterware先发现集群故障，他就会直接重组集群，尚存的节点锁住dead节点的journal，并恢复它；等clusterware重组之后，再通知上层的instance集群，使instance集群重组达到新的稳定状态
2.如果是instance集群先发现集群的故障，则rac会停止对外服务，并通知clusterware层集群完成集群重构，达到新的稳定状态，clusterware重构之后，在通知instance集群层，rac再开始重构；但是如果clusterware无法完成重构，那rac通过IMR机制自己重构集群以达到新的稳定状态
rac集群级联重启一般原因
主库的一个节点重启引起的voting磁盘hang住，导致其他节点无法访问，导致occsd进程故障，clusterware又检测到新集群故障，因此再次重组集群到新的稳定状态。
调整的根据
因为是由于voting磁盘长时间hang住不响应引起的其他节点的继续重启，
哪些参数可能因为磁盘hang引起重启
clusterware集群：o2cb的O2CB_HEARTBEAT_THRESHOLD每两秒更新一次系统文件（磁盘文件），以确定节点存活，如果超过阀值，就重启
rac集群：voting磁盘的disktimeout参数默认是200s,如果超过超过这个阀值，节点也会重启
我们的系统linux采用的多路径软件device-mapper-multipath
为了避免节点级联重启，可以通过增加clusterware的dead阀值来避免重启，根据以下公式（10.2.0.2版本以上）
O2CB_HEARTBEAT_THRESHOLD >= ((max(HW_STORAGE_TIMEOUT, SW_STORAGE_TIMEOUT) / 2) + 1)
disktimeout > max((O2CB_HEARTBEAT_THRESHOLD - 1) * 2, HW_STORAGE_TIMEOUT, SW_STORAGE_TIMEOUT)
所以将O2CB_HEARTBEAT_THRESHOLD=31调整为O2CB_HEARTBEAT_THRESHOLD=61（即由60秒增加到120秒），这样调整是为了给voting磁盘足够的recover时间，避免节点误重启
misscount参数先不调整，因为我们从重启的log里还没有直接发现是因为网络的原因，经过线下环境的测试发现，模拟ocfs2文件系统突然出问题，可再现和生产环境重启类似的日志信息。根据观察调整后情况，再看是否需要调整这个参数
调整O2CB_HEARTBEAT_THRESHOLD步骤
0.停止所有连接db的服务
1.停掉所有节点的crs
2.stop ocfs2服务
3.修改所有节点参数O2CB_HEARTBEAT_THRESHOLD
4.重启所有节点o2bc服务，启动ocfs2，启动crs服务
5.测试应用正常与否
影响
1、影响db对外服务时间
2、不会影响rac集群的稳定及数据的丢失
如果发现有异常问题，只需步骤把参数调回即可
参考文档
[ID 395878.1] [ID 457423.1] [ID 391771.1] [ID 294430.1]
---end---
