資料庫叢集自動重啟?Linux硬體錯誤日誌立大功!
環境:兩臺某想R680的物理機搭建一套2節點RAC,資料庫版本為ORACLE 11.2.0.4
一、故障問題現象
節點2頻繁發生重啟,從1月至2月發生多次重啟,甚至一天內3次重啟,讓人頭疼。
二、問題分析處理過程
1、檢查是否時間同步問題
首先懷疑是時間不同步造成的。
觀察現象是該伺服器的ntp時間同步offset過大(下圖offset為11376)
並在資料庫的CTSS日誌出現不正常的返回值
在這裡發現一個問題,就是時間源指向舊的時間源伺服器10.33.144.18和10.33.144.19,而伺服器在新的資料中心,所以修改為新資料的時間源伺服器11.8.13.1和11.8.13.9,並修改了BIOS時鐘,使系統時鐘和硬體時鐘時間一致。
至此,時間同步問題排除。
2、檢查資料庫日誌反應的問題
通過查ALERT日誌,發現有節點驅逐
又查CSSD日誌發現
顯示有磁碟的心跳,但無網路的心跳。
此時判斷:node 2 節點老是頻繁重啟,私網出問題的概率會較大,因此從網路處查。
node 2 每次重啟完以後,都能順利加入rac叢集,更不是時間同步的問題。
補充:
如果叢集中的節點連續丟失磁碟心跳或網路心跳,該節點就會被從叢集中驅逐,也就是節點重啟。組管理導致的節點重啟,我們稱之為node kill escalation(只有在11gR1以及以上版本適用)。
重啟需要在指定的時間(reboot time,一般為3秒)內完成。
網路心跳
如果某個節點連續丟失網路心跳達到閥值,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、解決問題靠的是耐心和細心,進一步再進一步,問題終會被解決。
文章出處:高效運維