因為diagwait未配置導致RAC腦裂日誌記錄不完整的分析案例,diagwaitrac
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