1. 程式人生 > >資料庫叢集自動重啟?Linux硬體錯誤日誌立大功!

資料庫叢集自動重啟?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日誌發現

Linux 硬體

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

此時判斷: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兩塊網絡卡組成,對應兩個交換機的兩個埠。

Linux 硬體

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

日誌

4、檢查是否是硬體的問題

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

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

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

MCELOG:不容忽視的日誌

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

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

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

日誌

ORACLE官方對MCELOG事件的解釋:

Linux 硬體錯誤日誌

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

三、問題總結與思考

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

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

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

文章出處:高效運維