前言

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

本期分享主題

小y今天要和大家分享的是下面這麽一個嚴肅的話題：

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

換句話說:

當Oracle RAC集群中的一個節點所在的分區/服務器宕掉的時候，

你是否可以和領導拍著胸脯說，

“沒事，這是ORACLE RAC，還有一個節點呢！只要該節點可以抗住負載，完全可以正常對外提供服務！”

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

小y再換個方法來問一下這個話題：

雖然系統上線前做過RAC高可用測試，但是當集群中的一個節點長時間運行，包括CPU、內存、進程數在內的負載在不斷變化，並且又經歷了一些列變更後，期間又沒有再做過高可用測試，這樣的情況下，如果RAC一個節點所在的分區/服務器宕掉的時候，你是否依然可以拍著胸脯堅定的說，“我的Oracle RAC其他的節點一定可以正常對外提供服務！”?

同樣的問題，當多了一些話語的鋪墊後，再次聽到這個問題的你，答案是否又更加猶豫了呢？

小y今天就為大家奉獻一個“RAC高可用丟失”的真實案例及其完整、真實的分析過程。

你可以從案例中獲得什麽

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

小y估計不少朋友的系統中依然還存在類似的問題，

建議參考本案例進行細致檢查,排除隱患。

。

案例精彩看點預告

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

Part 1

故障描述

現象：Oracle RAC高可用丟失。表現如下

1）下午16點1分左右，XX系統數據庫RAC集群節點2所在的P595 發生硬件故障，導致節點2 數據庫所在的分區不可用。

2）但從16點1分開始，應用程序無法連接到數據庫RAC集群中存活的節點1。

ORACLE數據庫RAC集群未能發揮高可用架構的作用！

客戶指示，務必找到問題根因，以便對系統高可用架構提出改進意見。

小y很理解，出了這樣的大事，對於一個運行著幾百套RAC的數據中心而言，是一個巨大的風險，其他系統是否也還存在這樣的問題？什麽時候會再發生？如果不找到問題根因，又如何做到由點帶面全面全面梳理、檢查和預防呢？

環境描述:

AIX 5.3

Oracle 10.2 2節點 RAC

HACMP+裸設備

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

1）故障時運維DBA在RAC存活節點1通過sqlplus “/as sysdba”連接到數據庫掛起

2）故障時運維DBA在RAC存活節點1通過sqlplus -prelim “/as sysdba”連接到數據庫掛起,加了-prelim參數連接到數據庫也hang,這是很罕見的情況

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

4）在存活的節點1上通過shutdown –Fr重啟操作系統，命令掛起無法結束，最終通過hmc重啟分區，業務恢復正常

Part 2

分析過程

2.1故障分析思路

集群中一個節點宕掉，其他節點無法對外提供服務。

通常情況下，是因為當中的集群軟件沒有完成對整個集群狀態、數據的重組，

因此數據未達到一致，所以集群其他節點無法對外提供服務。

這個環境中部署在IBM小機上，其中用到的集群軟件有：

ORACLE RAC/ORACLE CRS/IBM HACMP

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

2.2 確認ORACLE RAC是否完成重組

查看一節點數據庫alert日誌,可以看到，RAC集群在16點1分32秒就完成了重組。

可排除該問題。

2.3 確認ORACLE CRS是否完成重組

可以看到，從16:01開始網絡心跳超時，開始對節點2進行剔除的動作，最終在16:01:27節點2離開集群。可排除該問題。

2.4 確認IBM hacmp是否完成重組

經AIX專家分析，未發現HACMP中出現異常

整個檢查下來，沒有發現異常。

既然節點2數據庫所在的Lpar宕了，那麽節點2的vip應該會漂移到節點1上，接下來通過netstat –in命令檢查，發現節點1上居然沒有節點2飄過來的VIP ！

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

2.5 檢查1節點crs日誌確認節點2 vip的接管情況

2.6 節點1 crs日誌總結

可以看到：

1）節點2當掉後，節點1的CRS要把節點2的vip、db等資源接管過來，在節點1啟動，但是調用腳本racgwarp來做check/start/stop時均出現了超時timeout,從而把子進程終止了。

2）並且節點1 本身自己的 vip檢測中也出現了超時，如下所示

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

3） 因此，CRS在資源管理上也出現了一定的異常，主要是調用腳本racgwrap時出現了超時異常。

Racgwrap腳本出現timeout,通常是因為：

操作系統性能緩慢，如內存大量換頁

腳本執行過程出現命令掛起的情況

2.7 檢查nmon數據以獲得操作系統性能

可以看到,5月20日的nmon居然停止在了故障時間點16點1分，這說明NMON執行到某個命令可能出現了掛起等異常

另外，從監控軟件來看，操作系統未出現內存、CPU的告警。

2.8 確定分析方向

那麽，接下來，我們的分析重點到底是放在數據庫還是操作系統層面呢？

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

操作系統在當時出現了某些異常!因此後續把分析的重點方向放在操作系統層面！

2.9 匯總並梳理所有線索

1）存活節點Sqlplus –prelim無法attach到共享內存

2）Kill -9 無法殺掉部分進程

進程處於一個原子級的調用，例如一個IO，必須在兩個調用之間才可以接受進程終止的信號，說明某個原子調用無法結束導致無法被kill -9終止

3）CRS通過腳本無法接管故障節點vip,出現超時

4） CRS通過腳本無法檢測存活節點本身的vip/監聽等資源，均出現超時

5）存活節點Nmon故障點後無輸出

2.10 問題分析一度陷入僵局

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

AIX專家的結論是操作系統當時是沒有異常的！

因為他們檢查了一些crontab的腳本，是有輸出的，說明OS還在工作。

如下圖所示

2.11 如何找到突破口

小y把方向定到了操作系統，但是操作系統專家檢查並否認操作系統有異常。

對於存活節點nmon為什麽停止寫入的問題，雙方持不同意見。

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

1)如果沒有給到操作系統一個明確的點，那麽操作系統是很難查到到底有哪些異常的問題

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

3)堅信操作系統異常這個方向是正確的

回到原點，重新梳理和驗證每個線索，會不會漏掉了什麽重要線索

重現檢查之前的線索，有重大發現！

可以看到：

從16點02分以及後續的的采樣可以看到，到了” The file system result is as follows”的檢測就停止了，沒有寫SYSTEM.SH_RUN_COMPLETE關鍵字來表示腳本執行完成.這說明操作系統在執行非數據庫命令時也遇到了異常！

2.12 確認shell腳本出現異常時調用的具體命令

檢查shell腳本,發現腳本掛在” The file system result is as follows:”的地方，事實上是調用了df命令來查看文件系統。

那麽這個操作在什麽情況會出現HANG的情況呢。

答案是使用nfs文件系統的時候。

XX系統數據庫集群中使用了NFS文件系統，將節點2的/arch2文件系統通過NFS掛載到了節點1的/arch2文件系統上。當節點2出現硬件故障後，導致節點1無法與節點2的nfs server通訊，繼而導致節點1上，df命令查看文件系統時掛起。

由此來看，節點1 nmon數據停止的原因是df命令hang住了

但是這和節點1無法連接數據庫又有什麽關系呢？

當小y看到df命令時，淚奔了！

所有現象都可以得到解釋了！當所有現象都得到解釋的時候，心裏就踏實了！這意味著你找到了問題的根因，那麽預防措施就萬無一失了！

2.13 Nfs mount點丟失和無法連接數據庫的關系

執行連接數據庫操作時，需要獲取當前工作目錄(pwd)

但是由於AIX某些版本操作系統內部實現pwd過程的缺陷,導致必須遞歸到根目錄/下檢查目錄或文件的權限、類型.

當檢查到nfs時，由於nfs 以hard/background方式掛載，當nfs server不可用時，必然導致檢查nfs目錄時出現掛起，繼而導致了無法獲得pwd的輸出結果，繼而導致無法連接數據庫!

2.14 解開所有謎團

1） 存活節點Sqlplus –prelim無法attach到共享內存

獲取當前工作目錄時，由於nfs mount點丟失，get_cwd(pwd)掛起

2） Kill -9 無法殺掉部分進程

進程對nfs mount點進行IO操作，掛起，因此沒有機會收到進程終止信號

3） CRS通過腳本無法接管故障節點vip,出現超時

Racgwrap腳本中調用了pwd命令

4） CRS通過腳本無法檢測存活節點本身的vip/監聽等資源，均出現超時

Racgwrap腳本中調用了pwd命令

5） 存活節點Nmon故障點後無輸出

Nfs mount點丟失導致nmon調用df命令時掛起

2.15 再往前一步的分析

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

2.測試環境重現過程

節點2 mount /testfs到節點1的/testfs,停止節點2 nfs服務，未能重現。原因在於pwd的輸出為/oracle, 首字母o比t要小，因此未檢測到/testfs就獲得pwd結果而退出了

節點2 mount /aa到節點1的/aa,停止節點2 nfs服務，未能重現。原因是通過truss命令對比，發現生產和測試環境檢索/根目錄下的行為不一致，繼而檢查OS版本，發現測試環境OS版本較高

3.高版本的OS無法重現，低版本的操作系統可以重現，說明操作系統做了修正和增強，在ibm.com上已nfs hang搜索，可以發現IBM發布了APAR來修復該問題。

Part 3

原因總結和建議

3.1 原因總結

1、RAC集群節點2所在的P595 發生硬件故障，導致節點2 LPAR不可用。

繼而導致Nfs mount點丟失。

2、登陸數據庫時，需要獲取當前工作目錄(pwd)

3、但是由於AIX某些版本操作系統內部實現pwd過程的缺陷,導致必須遞 歸到根目錄/下檢查目錄或文件的權限、類型.

4、當檢查到nfs掛載點目錄/arch2時，由於nfs 以hard/background方式 掛載，當nfs server不可用時，必然導致檢查nfs目錄時出現掛起，繼 而導致了無法獲得pwd的輸出結果，繼而導致無法連接數據庫!

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

所有故障現象都可以得到解釋，如下：

1、存活節點Sqlplus –prelim無法attach到共享內存

獲取當前工作目錄時，由於nfs mount點丟失，get_cwd(pwd)掛起

2、Kill -9 無法殺掉部分進程

進程對nfs mount點進行IO操作，掛起，因此沒有機會收到進程終止信號

3、CRS通過腳本無法接管故障節點vip,出現超時

Racgwrap腳本中調用了pwd命令

4、CRS通過腳本無法檢測存活節點本身的vip/監聽等資源，均出現超時

Racgwrap腳本中調用了pwd命令

5、存活節點Nmon故障點後無輸出

Nfs mount點丟失導致nmon調用df命令時掛起

3.2 問題解決方案和建議

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

2） 使用gpfs代替nfs

3） 提供故障線索時，請勿根據個人經驗過濾掉認為不重要的信息

4） 安裝AIX APAR，改變操作系統get_cwd(pwd)調用的內部實現方式

5） 處理故障時Df命令hang的情況如果一開始就反饋給小y，那麽這個

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

6） 只在上線前做高可用測試是不夠的，因為上線後系統會經歷一系列的 變更，可能某些因素會報紙RAC冗余性丟失，建議定期做高可用測 試，可以選擇在變更窗口選擇逐個重啟實例、服務器的方式來進行驗證。

風險提醒之Oracle RAC高可用失效