如何進(jìn)行rac節(jié)點(diǎn)頻繁重啟的問(wèn)題分析

如何進(jìn)行rac節(jié)點(diǎn)頻繁重啟的問(wèn)題分析，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

環(huán)境：兩臺(tái)聯(lián)想R680的物理機(jī)搭建一套2節(jié)點(diǎn)RAC，數(shù)據(jù)庫(kù)版本為ORACLE 11.2.0.4

一、故障問(wèn)題現(xiàn)象：
節(jié)點(diǎn)2頻繁發(fā)生重啟，從1月至2月發(fā)生多次重啟，甚至一天內(nèi)3次重啟，讓人頭疼。

二、問(wèn)題分析處理過(guò)程：

1、時(shí)間同步問(wèn)題
首先懷疑是時(shí)間不同步造成的。
觀察現(xiàn)象是該服務(wù)器的ntp時(shí)間同步offset過(guò)大

并在數(shù)據(jù)庫(kù)的CTSS日志出現(xiàn)不正常的返回值

在這里發(fā)現(xiàn)一個(gè)問(wèn)題，就是時(shí)間源指向舊的時(shí)間源服務(wù)器，而服務(wù)器在新的數(shù)據(jù)中心，所以修改為新數(shù)據(jù)中心的時(shí)間源服務(wù)器并修改了BIOS時(shí)鐘，使系統(tǒng)時(shí)鐘和硬件時(shí)鐘時(shí)間一致。至此，時(shí)間同步問(wèn)題排除。

2、數(shù)據(jù)庫(kù)日志反應(yīng)的問(wèn)題

通過(guò)查ALERT日志，發(fā)現(xiàn)有節(jié)點(diǎn)驅(qū)逐

又查CSSD日志發(fā)現(xiàn)

顯示有磁盤的心跳，但無(wú)網(wǎng)絡(luò)的心跳。

此時(shí)判斷：node 2 節(jié)點(diǎn)老是頻繁重啟，私網(wǎng)出問(wèn)題的概率會(huì)較大，因此從網(wǎng)絡(luò)處查。node 2 每次重啟完以后，都能順利加入rac集群，更不是時(shí)間同步的問(wèn)題。 

補(bǔ)充：

如果集群中的節(jié)點(diǎn)連續(xù)丟失磁盤心跳或網(wǎng)絡(luò)心跳，該節(jié)點(diǎn)就會(huì)被從集群中驅(qū)逐，也就是節(jié)點(diǎn)重啟。組管理導(dǎo)致的節(jié)點(diǎn)重啟，我們稱之為node kill escalation（只有在11gR1以及以上版本適用）。重啟需要在指定的時(shí)間（reboot time,一般為3秒）內(nèi)完成。

網(wǎng)絡(luò)心跳:ocssd.bin進(jìn)程每秒鐘向集群中的各個(gè)節(jié)點(diǎn)通過(guò)私網(wǎng)發(fā)送網(wǎng)絡(luò)心跳信息，以確認(rèn)各個(gè)節(jié)點(diǎn)是否正常。如果某個(gè)節(jié)點(diǎn)連續(xù)丟失網(wǎng)絡(luò)心跳達(dá)到閥值，misscount（默認(rèn)為30秒，如果存在其他集群管理軟件則為600秒），集群會(huì)通過(guò)表決盤進(jìn)行投票，使丟失網(wǎng)絡(luò)心跳的節(jié)點(diǎn)被主節(jié)點(diǎn)驅(qū)逐出集群，即節(jié)點(diǎn)重啟。如果集群只包含2個(gè)節(jié)點(diǎn)，則會(huì)出現(xiàn)腦裂，結(jié)果是節(jié)點(diǎn)號(hào)小的節(jié)點(diǎn)存活下來(lái)，即使是節(jié)點(diǎn)號(hào)小的節(jié)點(diǎn)存在網(wǎng)絡(luò)問(wèn)題。

磁盤心跳：ocssd.bin進(jìn)程每秒鐘都會(huì)向所有表決盤（Voting File）注冊(cè)本節(jié)點(diǎn)的狀態(tài)信息，這個(gè)過(guò)程叫做磁盤心跳。如果某個(gè)節(jié)點(diǎn)連續(xù)丟失磁盤心跳達(dá)到閥值disk timeou(一般為200秒)，則該節(jié)點(diǎn)會(huì)自動(dòng)重啟以保證集群的一致性。另外，CRS只要求[N/2]+1個(gè)表決盤可用即可，其中N為表決盤數(shù)量，一般為奇數(shù)。

3、核查網(wǎng)絡(luò)的問(wèn)題

這套R(shí)AC的心跳網(wǎng)是由ETH13和ETH15兩塊網(wǎng)卡組成，對(duì)應(yīng)兩個(gè)交換機(jī)的兩個(gè)端口。

先后采取激活宕掉交換機(jī)兩個(gè)端口和網(wǎng)卡口沒(méi)有解決問(wèn)題，最后又采用換線、單獨(dú)拉線等解決辦法，發(fā)現(xiàn)線的光衰有點(diǎn)大，但重啟問(wèn)題沒(méi)有最終解決。

4、是否是硬件的問(wèn)題？

問(wèn)題至此陷入了困境，換個(gè)思路既然網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)都可能不是問(wèn)題，那么硬件真的能獨(dú)善其身，超然之外么？

答案是否定的，那就是硬件的問(wèn)題。

在節(jié)點(diǎn)發(fā)生重啟時(shí)，數(shù)據(jù)庫(kù)的日志里有中斷的現(xiàn)象，那么會(huì)不會(huì)是CPU和內(nèi)存的問(wèn)題呢？檢查下MCELOG日志就知道了。

MCELOG不容忽視的日志

mcelog 是 x86 的 Linux 系統(tǒng)上用來(lái)檢查硬件錯(cuò)誤，特別是內(nèi)存和CPU錯(cuò)誤的工具。它的日志就是MCELOG.

一般來(lái)說(shuō)大內(nèi)存的服務(wù)器容易出現(xiàn)內(nèi)存上的問(wèn)題，現(xiàn)在內(nèi)存控制器都是集成在cpu里，內(nèi)存的校驗(yàn)錯(cuò)誤和CPU的問(wèn)題易引起服務(wù)器的重啟。

至此，問(wèn)題浮出水面。和硬件廠商聯(lián)系，刷主板固件程序，更換一根內(nèi)存后問(wèn)題最終解決。

三、問(wèn)題總結(jié)與思考：

1、不能忽視監(jiān)控的作用。這次內(nèi)存硬件的問(wèn)題，在服務(wù)器硬件監(jiān)控平臺(tái)沒(méi)有被發(fā)現(xiàn)，這個(gè)需要聯(lián)系廠商，繼續(xù)完善服務(wù)器硬件監(jiān)控的細(xì)粒度和敏感性

2、從日志、網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、系統(tǒng)、硬件等方面全面排查，問(wèn)題終會(huì)被發(fā)現(xiàn)。

3、解決問(wèn)題靠的是耐心和細(xì)心，進(jìn)一步再進(jìn)一步，問(wèn)題終會(huì)被解決。

看完上述內(nèi)容，你們掌握如何進(jìn)行rac節(jié)點(diǎn)頻繁重啟的問(wèn)題分析的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！