前言

網(wǎng)站是企業(yè)的互聯(lián)網(wǎng)名片，是開展互聯(lián)網(wǎng)業(yè)務(wù)基礎(chǔ)平臺。在目標(biāo)明確的基礎(chǔ)上，創(chuàng)新互聯(lián)憑借團(tuán)隊(duì)豐富的設(shè)計(jì)經(jīng)驗(yàn)完成網(wǎng)站的構(gòu)思創(chuàng)意即總體設(shè)計(jì)方案，自成立以來，一直致力于為企業(yè)提供從域名與空間、網(wǎng)站策劃、網(wǎng)站設(shè)計(jì)、品牌網(wǎng)站設(shè)計(jì)、電子商務(wù)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站推廣、網(wǎng)站優(yōu)化到為企業(yè)提供個(gè)性化軟件開發(fā)等基于互聯(lián)網(wǎng)的全面整合營銷服務(wù)。

不知不覺，技術(shù)人生·我和數(shù)據(jù)中心的故事來到了第二期，有朋友開始關(guān)心小y是誰，這不重要，我們更關(guān)心的是技術(shù)層面的分享以及給客戶帶來的實(shí)際的風(fēng)險(xiǎn)提示。后續(xù)我們還會繼續(xù)分享中包括操作系統(tǒng)的小亦，中間件的小W的故事....小y這個(gè)名字，其實(shí)沒有什么特殊的含義，就暫且用他來代表我們這些為數(shù)據(jù)中心奉獻(xiàn)自己無悔青春的運(yùn)維人吧！

本期分享主題

小y今天要和大家分享的是下面這么一個(gè)嚴(yán)肅的話題：

你的Oracle RAC是真的高可用么？還是偽高可用呢？

換句話說:

當(dāng)Oracle RAC集群中的一個(gè)節(jié)點(diǎn)所在的分區(qū)/服務(wù)器宕掉的時(shí)候，

你是否可以和領(lǐng)導(dǎo)拍著胸脯說，

“沒事，這是ORACLE RAC，還有一個(gè)節(jié)點(diǎn)呢！只要該節(jié)點(diǎn)可以抗住負(fù)載，完全可以正常對外提供服務(wù)！”

如果你再把上面那段話讀一遍，是否有開始猶豫的感覺了呢？

小y再換個(gè)方法來問一下這個(gè)話題：

雖然系統(tǒng)上線前做過RAC高可用測試，但是當(dāng)集群中的一個(gè)節(jié)點(diǎn)長時(shí)間運(yùn)行，包括CPU、內(nèi)存、進(jìn)程數(shù)在內(nèi)的負(fù)載在不斷變化，并且又經(jīng)歷了一些列變更后，期間又沒有再做過高可用測試，這樣的情況下，如果RAC一個(gè)節(jié)點(diǎn)所在的分區(qū)/服務(wù)器宕掉的時(shí)候，你是否依然可以拍著胸脯堅(jiān)定的說，“我的Oracle RAC其他的節(jié)點(diǎn)一定可以正常對外提供服務(wù)！”?

同樣的問題，當(dāng)多了一些話語的鋪墊后，再次聽到這個(gè)問題的你，答案是否又更加猶豫了呢？

小y今天就為大家奉獻(xiàn)一個(gè)“RAC高可用丟失”的真實(shí)案例及其完整、真實(shí)的分析過程。

你可以從案例中獲得什么

了解到導(dǎo)致Oracle RAC高可用失效的一些具體因素。

小y估計(jì)不少朋友的系統(tǒng)中依然還存在類似的問題，

建議參考本案例進(jìn)行細(xì)致檢查,排除隱患。

。

案例精彩看點(diǎn)預(yù)告

這個(gè)案例會有不小的難度，客戶為了分析該問題發(fā)生的根因，投入了大量的人力和時(shí)間，一度沒有結(jié)果。小y接手該case后，在缺少信息的情況下，問題的分析也一度陷入僵局。不過小y最終還是通過反復(fù)梳理所有線索，從一個(gè)和數(shù)據(jù)庫毫不相關(guān)的小細(xì)節(jié)中找到了突破口，成功定位到了問題原因。大家可以借鑒一下這樣的方法。

Part 1

故障描述

現(xiàn)象：Oracle RAC高可用丟失。表現(xiàn)如下

1）下午16點(diǎn)1分左右，XX系統(tǒng)數(shù)據(jù)庫RAC集群節(jié)點(diǎn)2所在的P595 發(fā)生硬件故障，導(dǎo)致節(jié)點(diǎn)2 數(shù)據(jù)庫所在的分區(qū)不可用。

2）但從16點(diǎn)1分開始，應(yīng)用程序無法連接到數(shù)據(jù)庫RAC集群中存活的節(jié)點(diǎn)1。

ORACLE數(shù)據(jù)庫RAC集群未能發(fā)揮高可用架構(gòu)的作用！

客戶指示，務(wù)必找到問題根因，以便對系統(tǒng)高可用架構(gòu)提出改進(jìn)意見。

小y很理解，出了這樣的大事，對于一個(gè)運(yùn)行著幾百套RAC的數(shù)據(jù)中心而言，是一個(gè)巨大的風(fēng)險(xiǎn)，其他系統(tǒng)是否也還存在這樣的問題？什么時(shí)候會再發(fā)生？如果不找到問題根因，又如何做到由點(diǎn)帶面全面全面梳理、檢查和預(yù)防呢？

環(huán)境描述:

AIX 5.3

Oracle 10.2 2節(jié)點(diǎn) RAC

HACMP+裸設(shè)備

所以，小y接到該case時(shí)，還是有很大壓力的。在開始分析前，小y得到了以下信息：

1）故障時(shí)運(yùn)維DBA在RAC存活節(jié)點(diǎn)1通過sqlplus “/as sysdba”連接到數(shù)據(jù)庫掛起

2）故障時(shí)運(yùn)維DBA在RAC存活節(jié)點(diǎn)1通過sqlplus -prelim “/as sysdba”連接到數(shù)據(jù)庫掛起,加了-prelim參數(shù)連接到數(shù)據(jù)庫也hang,這是很罕見的情況

3）在存活的節(jié)點(diǎn)1上通過 crsctl stop crs -f停止crs無法停止,命令掛起無法結(jié)束

4）在存活的節(jié)點(diǎn)1上通過shutdown –Fr重啟操作系統(tǒng)，命令掛起無法結(jié)束，最終通過hmc重啟分區(qū)，業(yè)務(wù)恢復(fù)正常

Part 2

分析過程

2.1故障分析思路

集群中一個(gè)節(jié)點(diǎn)宕掉，其他節(jié)點(diǎn)無法對外提供服務(wù)。

通常情況下，是因?yàn)楫?dāng)中的集群軟件沒有完成對整個(gè)集群狀態(tài)、數(shù)據(jù)的重組，

因此數(shù)據(jù)未達(dá)到一致，所以集群其他節(jié)點(diǎn)無法對外提供服務(wù)。

這個(gè)環(huán)境中部署在IBM小機(jī)上，其中用到的集群軟件有：

ORACLE RAC/ORACLE CRS/IBM HACMP

因此，需要分別查看這三個(gè)集群是否完成了重組、重新配置

2.2 確認(rèn)ORACLE RAC是否完成重組

查看一節(jié)點(diǎn)數(shù)據(jù)庫alert日志,可以看到，RAC集群在16點(diǎn)1分32秒就完成了重組。

可排除該問題。

2.3 確認(rèn)ORACLE CRS是否完成重組

可以看到，從16:01開始網(wǎng)絡(luò)心跳超時(shí)，開始對節(jié)點(diǎn)2進(jìn)行剔除的動作，最終在16:01:27節(jié)點(diǎn)2離開集群。可排除該問題。

2.4 確認(rèn)IBM hacmp是否完成重組

經(jīng)AIX專家分析，未發(fā)現(xiàn)HACMP中出現(xiàn)異常

整個(gè)檢查下來，沒有發(fā)現(xiàn)異常。

既然節(jié)點(diǎn)2數(shù)據(jù)庫所在的Lpar宕了，那么節(jié)點(diǎn)2的vip應(yīng)該會漂移到節(jié)點(diǎn)1上，接下來通過netstat –in命令檢查，發(fā)現(xiàn)節(jié)點(diǎn)1上居然沒有節(jié)點(diǎn)2飄過來的VIP ！

接管VIP的動作最終將由CRSD進(jìn)程來完成，因此檢查CRSD.log,以便查看是否在接管過程中發(fā)生了什么異常。

2.5 檢查1節(jié)點(diǎn)crs日志確認(rèn)節(jié)點(diǎn)2 vip的接管情況

2.6 節(jié)點(diǎn)1 crs日志總結(jié)

可以看到：

1）節(jié)點(diǎn)2當(dāng)?shù)艉?，?jié)點(diǎn)1的CRS要把節(jié)點(diǎn)2的vip、db等資源接管過來，在節(jié)點(diǎn)1啟動，但是調(diào)用腳本racgwarp來做check/start/stop時(shí)均出現(xiàn)了超時(shí)timeout,從而把子進(jìn)程終止了。

2）并且節(jié)點(diǎn)1 本身自己的 vip檢測中也出現(xiàn)了超時(shí)，如下所示

/oracle/app/oracle/product/10.2.0/crs/bin/racgwrap(check) timed out for ora.node1.vip! (timeout=60)

3） 因此，CRS在資源管理上也出現(xiàn)了一定的異常，主要是調(diào)用腳本racgwrap時(shí)出現(xiàn)了超時(shí)異常。

Racgwrap腳本出現(xiàn)timeout,通常是因?yàn)椋?/p>

操作系統(tǒng)性能緩慢，如內(nèi)存大量換頁

腳本執(zhí)行過程出現(xiàn)命令掛起的情況

2.7 檢查nmon數(shù)據(jù)以獲得操作系統(tǒng)性能

可以看到,5月20日的nmon居然停止在了故障時(shí)間點(diǎn)16點(diǎn)1分，這說明NMON執(zhí)行到某個(gè)命令可能出現(xiàn)了掛起等異常

另外，從監(jiān)控軟件來看，操作系統(tǒng)未出現(xiàn)內(nèi)存、CPU的告警。

2.8 確定分析方向

那么，接下來，我們的分析重點(diǎn)到底是放在數(shù)據(jù)庫還是操作系統(tǒng)層面呢？

通過上面的線索梳理，我們有理由相信：

操作系統(tǒng)在當(dāng)時(shí)出現(xiàn)了某些異常!因此后續(xù)把分析的重點(diǎn)方向放在操作系統(tǒng)層面！

2.9 匯總并梳理所有線索

1）存活節(jié)點(diǎn)Sqlplus –prelim無法attach到共享內(nèi)存

2）Kill -9 無法殺掉部分進(jìn)程

進(jìn)程處于一個(gè)原子級的調(diào)用，例如一個(gè)IO，必須在兩個(gè)調(diào)用之間才可以接受進(jìn)程終止的信號，說明某個(gè)原子調(diào)用無法結(jié)束導(dǎo)致無法被kill -9終止

3）CRS通過腳本無法接管故障節(jié)點(diǎn)vip,出現(xiàn)超時(shí)

4） CRS通過腳本無法檢測存活節(jié)點(diǎn)本身的vip/監(jiān)聽等資源，均出現(xiàn)超時(shí)

5）存活節(jié)點(diǎn)Nmon故障點(diǎn)后無輸出

2.10 問題分析一度陷入僵局

雖然把方向放在操作系統(tǒng)上，但AIX專家未檢查到異常。

AIX專家的結(jié)論是操作系統(tǒng)當(dāng)時(shí)是沒有異常的！

因?yàn)樗麄儥z查了一些crontab的腳本，是有輸出的，說明OS還在工作。

如下圖所示

2.11 如何找到突破口

小y把方向定到了操作系統(tǒng)，但是操作系統(tǒng)專家檢查并否認(rèn)操作系統(tǒng)有異常。

對于存活節(jié)點(diǎn)nmon為什么停止寫入的問題，雙方持不同意見。

至此，問題分析陷入僵局，小y開始思考，該如何繼續(xù)往下分析呢？怎么能證明操作系統(tǒng)的異常呢？

1)如果沒有給到操作系統(tǒng)一個(gè)明確的點(diǎn)，那么操作系統(tǒng)是很難查到到底有哪些異常的問題

2)問題分析陷入僵局，該如何找到突破口成為關(guān)鍵

3)堅(jiān)信操作系統(tǒng)異常這個(gè)方向是正確的

回到原點(diǎn)，重新梳理和驗(yàn)證每個(gè)線索，會不會漏掉了什么重要線索

重現(xiàn)檢查之前的線索，有重大發(fā)現(xiàn)！

可以看到：

從16點(diǎn)02分以及后續(xù)的的采樣可以看到，到了” The file system result is as follows”的檢測就停止了，沒有寫SYSTEM.SH_RUN_COMPLETE關(guān)鍵字來表示腳本執(zhí)行完成.這說明操作系統(tǒng)在執(zhí)行非數(shù)據(jù)庫命令時(shí)也遇到了異常！

2.12 確認(rèn)shell腳本出現(xiàn)異常時(shí)調(diào)用的具體命令

檢查shell腳本,發(fā)現(xiàn)腳本掛在” The file system result is as follows:”的地方，事實(shí)上是調(diào)用了df命令來查看文件系統(tǒng)。

那么這個(gè)操作在什么情況會出現(xiàn)HANG的情況呢。

答案是使用nfs文件系統(tǒng)的時(shí)候。

XX系統(tǒng)數(shù)據(jù)庫集群中使用了NFS文件系統(tǒng)，將節(jié)點(diǎn)2的/arch3文件系統(tǒng)通過NFS掛載到了節(jié)點(diǎn)1的/arch3文件系統(tǒng)上。當(dāng)節(jié)點(diǎn)2出現(xiàn)硬件故障后，導(dǎo)致節(jié)點(diǎn)1無法與節(jié)點(diǎn)2的nfs server通訊，繼而導(dǎo)致節(jié)點(diǎn)1上，df命令查看文件系統(tǒng)時(shí)掛起。

由此來看，節(jié)點(diǎn)1 nmon數(shù)據(jù)停止的原因是df命令hang住了

但是這和節(jié)點(diǎn)1無法連接數(shù)據(jù)庫又有什么關(guān)系呢？

當(dāng)小y看到df命令時(shí)，淚奔了！

所有現(xiàn)象都可以得到解釋了！當(dāng)所有現(xiàn)象都得到解釋的時(shí)候，心里就踏實(shí)了！這意味著你找到了問題的根因，那么預(yù)防措施就萬無一失了！

2.13 Nfs mount點(diǎn)丟失和無法連接數(shù)據(jù)庫的關(guān)系

執(zhí)行連接數(shù)據(jù)庫操作時(shí)，需要獲取當(dāng)前工作目錄(pwd)

但是由于AIX某些版本操作系統(tǒng)內(nèi)部實(shí)現(xiàn)pwd過程的缺陷,導(dǎo)致必須遞歸到根目錄/下檢查目錄或文件的權(quán)限、類型.

當(dāng)檢查到nfs時(shí)，由于nfs 以hard/background方式掛載，當(dāng)nfs server不可用時(shí)，必然導(dǎo)致檢查nfs目錄時(shí)出現(xiàn)掛起，繼而導(dǎo)致了無法獲得pwd的輸出結(jié)果，繼而導(dǎo)致無法連接數(shù)據(jù)庫!

2.14 解開所有謎團(tuán)

1） 存活節(jié)點(diǎn)Sqlplus –prelim無法attach到共享內(nèi)存

獲取當(dāng)前工作目錄時(shí)，由于nfs mount點(diǎn)丟失，get_cwd(pwd)掛起

2） Kill -9 無法殺掉部分進(jìn)程

進(jìn)程對nfs mount點(diǎn)進(jìn)行IO操作，掛起，因此沒有機(jī)會收到進(jìn)程終止信號

3） CRS通過腳本無法接管故障節(jié)點(diǎn)vip,出現(xiàn)超時(shí)

Racgwrap腳本中調(diào)用了pwd命令

4） CRS通過腳本無法檢測存活節(jié)點(diǎn)本身的vip/監(jiān)聽等資源，均出現(xiàn)超時(shí)

Racgwrap腳本中調(diào)用了pwd命令

5） 存活節(jié)點(diǎn)Nmon故障點(diǎn)后無輸出

Nfs mount點(diǎn)丟失導(dǎo)致nmon調(diào)用df命令時(shí)掛起

2.15 再往前一步的分析

1.該機(jī)制下，如果根目錄/小文件或目錄很多，則pwd(get_cwd)的性能會很差

2.測試環(huán)境重現(xiàn)過程

節(jié)點(diǎn)2 mount /testfs到節(jié)點(diǎn)1的/testfs,停止節(jié)點(diǎn)2 nfs服務(wù)，未能重現(xiàn)。原因在于pwd的輸出為/oracle, 首字母o比t要小，因此未檢測到/testfs就獲得pwd結(jié)果而退出了

節(jié)點(diǎn)2 mount /aa到節(jié)點(diǎn)1的/aa,停止節(jié)點(diǎn)2 nfs服務(wù)，未能重現(xiàn)。原因是通過truss命令對比，發(fā)現(xiàn)生產(chǎn)和測試環(huán)境檢索/根目錄下的行為不一致，繼而檢查OS版本，發(fā)現(xiàn)測試環(huán)境OS版本較高

3.高版本的OS無法重現(xiàn)，低版本的操作系統(tǒng)可以重現(xiàn)，說明操作系統(tǒng)做了修正和增強(qiáng)，在ibm.com上已nfs hang搜索，可以發(fā)現(xiàn)IBM發(fā)布了APAR來修復(fù)該問題。

Part 3

原因總結(jié)和建議

3.1 原因總結(jié)

1、RAC集群節(jié)點(diǎn)2所在的P595 發(fā)生硬件故障，導(dǎo)致節(jié)點(diǎn)2 LPAR不可用。

繼而導(dǎo)致Nfs mount點(diǎn)丟失。

2、登陸數(shù)據(jù)庫時(shí)，需要獲取當(dāng)前工作目錄(pwd)

3、但是由于AIX某些版本操作系統(tǒng)內(nèi)部實(shí)現(xiàn)pwd過程的缺陷,導(dǎo)致必須遞 歸到根目錄/下檢查目錄或文件的權(quán)限、類型.

4、當(dāng)檢查到nfs掛載點(diǎn)目錄/arch3時(shí)，由于nfs 以hard/background方式 掛載，當(dāng)nfs server不可用時(shí)，必然導(dǎo)致檢查nfs目錄時(shí)出現(xiàn)掛起，繼 而導(dǎo)致了無法獲得pwd的輸出結(jié)果，繼而導(dǎo)致無法連接數(shù)據(jù)庫!

以hard/background掛載的NFS server丟失是導(dǎo)致RAC成為偽集群的根本原因！

所有故障現(xiàn)象都可以得到解釋，如下：

1、存活節(jié)點(diǎn)Sqlplus –prelim無法attach到共享內(nèi)存

獲取當(dāng)前工作目錄時(shí)，由于nfs mount點(diǎn)丟失，get_cwd(pwd)掛起

2、Kill -9 無法殺掉部分進(jìn)程

進(jìn)程對nfs mount點(diǎn)進(jìn)行IO操作，掛起，因此沒有機(jī)會收到進(jìn)程終止信號

3、CRS通過腳本無法接管故障節(jié)點(diǎn)vip,出現(xiàn)超時(shí)

Racgwrap腳本中調(diào)用了pwd命令

4、CRS通過腳本無法檢測存活節(jié)點(diǎn)本身的vip/監(jiān)聽等資源，均出現(xiàn)超時(shí)

Racgwrap腳本中調(diào)用了pwd命令

5、存活節(jié)點(diǎn)Nmon故障點(diǎn)后無輸出

Nfs mount點(diǎn)丟失導(dǎo)致nmon調(diào)用df命令時(shí)掛起

3.2 問題解決方案和建議

1） 如果需要實(shí)用nfs,則mount到二級目錄，比如mount到/home /arch 2而不是/arch3

2） 使用gpfs代替nfs

3） 提供故障線索時(shí)，請勿根據(jù)個(gè)人經(jīng)驗(yàn)過濾掉認(rèn)為不重要的信息

4） 安裝AIX APAR，改變操作系統(tǒng)get_cwd(pwd)調(diào)用的內(nèi)部實(shí)現(xiàn)方式

5） 處理故障時(shí)Df命令hang的情況如果一開始就反饋給小y，那么這個(gè)

case直接就解開了，就不需要查了！

6） 只在上線前做高可用測試是不夠的，因?yàn)樯暇€后系統(tǒng)會經(jīng)歷一系列的 變更，可能某些因素會報(bào)紙RAC冗余性丟失，建議定期做高可用測 試，可以選擇在變更窗口選擇逐個(gè)重啟實(shí)例、服務(wù)器的方式來進(jìn)行驗(yàn)證。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

標(biāo)題名稱：風(fēng)險(xiǎn)提醒之OracleRAC高可用失效-創(chuàng)新互聯(lián)
文章位置：http://chinadenli.net/article2/dgpioc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、網(wǎng)站內(nèi)鏈、用戶體驗(yàn)、網(wǎng)站排名、網(wǎng)站策劃、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)