rac節點頻繁重啟的問題分析

• 2019 年 10 月 29 日
• 筆記

環境：兩台聯想R680的物理機搭建一套2節點RAC，資料庫版本為ORACLE 11.2.0.4

一、故障問題現象： 節點2頻繁發生重啟，從1月至2月發生多次重啟，甚至一天內3次重啟，讓人頭疼。

二、問題分析處理過程：

1、時間同步問題 首先懷疑是時間不同步造成的。 觀察現象是該伺服器的ntp時間同步offset過大（下圖offset為11376）

並在資料庫的CTSS日誌出現不正常的返回值

在這裡發現一個問題，就是時間源指向舊的時間源伺服器，而伺服器在新的數據中心，所以修改為新數據中心的時間源伺服器並修改了BIOS時鐘，使系統時鐘和硬體時鐘時間一致。至此，時間同步問題排除。

2、資料庫日誌反應的問題

通過查ALERT日誌，發現有節點驅逐

又查CSSD日誌發現

顯示有磁碟的心跳，但無網路的心跳。

此時判斷：node 2 節點老是頻繁重啟，私網出問題的概率會較大，因此從網路處查。node 2 每次重啟完以後，都能順利加入rac集群，更不是時間同步的問題。 

補充：

如果集群中的節點連續丟失磁碟心跳或網路心跳，該節點就會被從集群中驅逐，也就是節點重啟。組管理導致的節點重啟，我們稱之為node kill escalation（只有在11gR1以及以上版本適用）。重啟需要在指定的時間（reboot time,一般為3秒）內完成。

網路心跳:ocssd.bin進程每秒鐘向集群中的各個節點通過私網發送網路心跳資訊，以確認各個節點是否正常。如果某個節點連續丟失網路心跳達到閥值，misscount（默認為30秒，如果存在其他集群管理軟體則為600秒），集群會通過表決盤進行投票，使丟失網路心跳的節點被主節點驅逐出集群，即節點重啟。如果集群只包含2個節點，則會出現腦裂，結果是節點號小的節點存活下來，即使是節點號小的節點存在網路問題。

磁碟心跳：ocssd.bin進程每秒鐘都會向所有表決盤（Voting File）註冊本節點的狀態資訊，這個過程叫做磁碟心跳。如果某個節點連續丟失磁碟心跳達到閥值disk timeou(一般為200秒)，則該節點會自動重啟以保證集群的一致性。另外，CRS只要求[N/2]+1個表決盤可用即可，其中N為表決盤數量，一般為奇數。

3、核查網路的問題

這套RAC的心跳網是由ETH13和ETH15兩塊網卡組成，對應兩個交換機的兩個埠。

先後採取激活宕掉交換機兩個埠和網卡口沒有解決問題，最後又採用換線、單獨拉線等解決辦法，發現線的光衰有點大，但重啟問題沒有最終解決。

4、是否是硬體的問題？

問題至此陷入了困境，換個思路既然網路和資料庫都可能不是問題，那麼硬體真的能獨善其身，超然之外么？

答案是否定的，那就是硬體的問題。

在節點發生重啟時，資料庫的日誌里有中斷的現象，那麼會不會是CPU和記憶體的問題呢？檢查下MCELOG日誌就知道了。

MCELOG不容忽視的日誌

mcelog 是 x86 的 Linux 系統上用來檢查硬體錯誤，特別是記憶體和CPU錯誤的工具。它的日誌就是MCELOG.

一般來說大記憶體的伺服器容易出現記憶體上的問題，現在記憶體控制器都是集成在cpu里，記憶體的校驗錯誤和CPU的問題易引起伺服器的重啟。

好了，下面我們看看MCELOG日誌的錯誤提示

ORACLE官方對MCELOG事件的解釋：

至此，問題浮出水面。和硬體廠商聯繫，刷主板韌體程式，更換一根記憶體後問題最終解決。

三、問題總結與思考：

1、不能忽視監控的作用。這次記憶體硬體的問題，在伺服器硬體監控平台沒有被發現，這個需要聯繫廠商，繼續完善伺服器硬體監控的細粒度和敏感性

2、從日誌、網路、資料庫、系統、硬體等方面全面排查，問題終會被發現。

3、解決問題靠的是耐心和細心，進一步再進一步，問題終會被解決。