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