rac集群节点级联重启故障分析

无意中发现以前处理故障写的一篇文章，记录下来以备查找。

www.2cto.com

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机制自己重构集群以达到新的稳定状态

www.2cto.com

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文件系统突然出问题，可再现和生产环境重启类似的日志信息。根据观察调整后情况，再看是否需要调整这个参数

www.2cto.com

调整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]

作者 skate