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

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---