Oracle12C RAC節點損壞恢復方案研究

王 健，王啟明

（中國鐵路北京局集團有限公司 信息技術所，北京 100860）

Oracle RAC在業界以高并行性和高可用性著稱，其優勢在于使用多個節點（數據庫實例）構成一個數據庫[1]，在保證數據庫高可用性的前提下更加充分的利用了多臺主機的性能，RAC還可以通過增加集群節點進行性能擴展，為需要重新規劃的應用提供了易伸縮性，以滿足系統自身的調整。

在國內數據庫市場，企業對數據庫系統的穩定性和高可用性的要求越來越高，大部分企業選擇Oracle RAC作為核心數據庫[2],但在實際運維中會遇到服務器、操作系統、存儲等軟硬件設備故障導致RAC集群節點損壞的問題，此時集群的優勢即會折損，后臺數據庫系統是否具有高可用性，能否保障關鍵數據的完整性和核心業務的連續性，成為影響大局的關鍵因素，而目前Oracle相關資料文獻少有涉及RAC集群節點損壞恢復的完整方案，本文從實際案例出發，針對初次采用的Windows平臺下Oracle12C RAC集群架構，介紹了本單位RAC節點損壞后，進行在線恢復的詳細過程以及相關bug的解決辦法，為后續數據庫系統的運行維護積累了實用且寶貴的經驗。

1 Oracle RAC原理及特點

Oracle RAC （Oracle Real Application Clusters）是Oracle新數據庫版本中采用的一項新技術，也是Oracle支持網格計算環境的核心技術，解決了傳統數據庫應用中的高可用性問題[3]。

1.1 Oracle RAC原理

Oracle RAC工作原理是指在一個應用環境當中，所有的服務器管理和使用同一個數據庫，目的是為了分散每臺服務器的工作量，硬件設備至少需要兩臺及以上的服務器，并且還需要一臺共享存儲設備[4]。同時需要的軟件有兩類：集群軟件和Oracle數據庫中的RAC組件。所有服務器上的OS都應該保持版本一致,當某客戶端發送請求到某臺服務器的listener后，此服務器根據負載均衡配置策略，會把請求發送到本機的RAC組件處理也可能會發送到另外一臺服務器的RAC組件，請求處理完成后，RAC會通過集群軟件訪問共享存儲設備。從邏輯結構上看，每一個集群節點都有一個獨立的實例，這些實例訪問同一個數據庫，節點間通過集群軟件的通訊層來進行通訊。同時，為了減少I/O的消耗，采用了Cache Fusion[5]緩存融合技術，因此每一個數據庫的實例，都保存了一份相同的數據庫Cache，Oracle RAC結構如圖1所示。

圖1 Oracle RAC工作結構圖

1.2 Oracle RAC特點

不同的集群產品都有各自的特點，RAC的特點包括：

（1）雙機并行。RAC是并行模式，不是傳統的主備模式。就是說，RAC集群的全部成員都能同時接收客戶端的請求。

（2）高可用性。RAC是Oracle產品的高可用性解決方案，集群中只要還有一個節點存活，就能保證正常對外提供服務。

（3）易伸縮性。RAC能動態添加、刪除節點，來滿足系統自身的調整。

（4）低成本。能使用相對廉價的服務器來實現高吞吐量、高可用性的集群環境，這比對高端服務器增加硬件來實現高吞吐量、高可用性花費的成本低很多。

（5）高吞吐量。隨著集群節點數量的增加，整個RAC的吞吐量也會不斷增長[6]。

2 系統及數據庫環境分析

2.1 既有系統及數據庫環境

傳統數據中心核心業務和關鍵業務的計算及存儲主要都由RISC小型機完成，伴隨著X86處理器可靠性及性能的提升，這些業務正在逐步遷移到X86平臺[7]。2016年，本單位投產的貨運系統，后臺數據庫環境整體都采用X86硬件架構，數據庫操作系統為Windows Server 2012，為了保障系統的高可用性和業務并行處理能力，搭建了4節點Oracle12C RAC集群，配置信息如表1所示。

2.2 存在問題

如表1所示的多點數據庫集群模式運行狀態穩定，能夠有效解決高并發訪問情況下的單點瓶頸問題[8]， 但是在勒索病毒爆發后，為計算機安裝最新的安全補丁，修復“永恒之藍”攻擊漏洞的過程中,節點2在打完補丁重啟后未能正常引導進入操作系統，最終節點系統崩潰，導致集群變為3節點運行，運行架構如圖2所示。

表1 Oracle RAC配置信息

圖2 Oracle RAC運行架構

雖然一個節點的損壞不會影響整體業務的正常運行，但是為計算機安裝安全補丁是一件常態化的工作，甚至計算機本地磁盤組損壞都是系統運維中會遇到的問題，因此，不能讓集群節點一味被動的削減，我們需要重新配置Oracle集群信息，在保證業務正常運行的前提下，在線修復損壞節點，恢復RAC集群原有結構，保證核心系統的高可用性。

2.3 研究方法及實現目標

雖然Oracle RAC為需要重新規劃的應用提供了易伸縮性，可以動態地添加、刪除節點，以滿足系統自身的調整規劃，但目前Windows Server 2012+Oracle 12C RAC實施案例較少，通過查閱Oracle官方技術支持站點獲取幫助資料，參考以往Unix、Linux平臺Oracle 11g R2 RAC添加、刪除節點實施案例，借鑒其中的關鍵技術及成功經驗，進而實現以下目標：

（1）能夠在不停集群即保證現場貨運業務連續性的情況下，獲得水平的擴展，要在保留節點刪除之前損壞的數據庫實例，在集群中刪除故障節點的信息后，在線新增節點，恢復集群原有架構。

（2）對整個實施過程以及在過程中遇到的各類問題認真總結，為X86架構Windows平臺下Oracle RAC集群運維積累經驗，提高數據庫系統管理水平，確保核心系統運行安全穩定。

3 方案實施步驟

3.1 恢復前工作準備

3.1.1 操作系統安裝

對損壞的集群節點2重新安裝操作系統，要求與其他節點版本保持一致，更改主機名為tjhyrac2。

3.1.2 操作系統配置

（1）Host表修改

從保留節點的C:WindowsSystem32driversetchosts 復制到節點2相應的目錄。

（2）網絡配置

配置公網和私網IP。設置節點2兩塊網卡的IP地址，分別命名為Pub和Priv并設置網卡優先級，將Pub網卡設置為優先。

（3）服務配置

安裝相關服務、開啟遠程桌面訪問，將節點2上的Computer Browser設置為自動和啟動狀態。

（4）注冊表配置

（5）共享配置

在節點2服務器上，使用net use命令配置節點間通信[9]：

在其他各節點運行：

（6）存儲配置

在磁盤管理中，各磁盤刪除磁盤號，然后直接聯機。

3.1.3 數據備份

選擇現場應用相對空閑時段進行節點恢復，恢復前可使用常用的3種備份方法：RMAN備份、邏輯備份和冷備份[10]，或將數據庫遷移至第三方環境。

3.2 損壞節點在線恢復

RAC集群中節點2系統出現故障，需要刪除節點2信息，添加新節點。

3.2.1 刪除節點

（1）節點確認

登錄任一節點，執行：

在保留節點查看節點信息是否為unpin狀態，如果不是使用下面命令，將節點設置為unpin狀態。

crsctl unpin css -n（節點主機名）

（2）刪除故障節點實例

在保留節點使用Oracle用戶通過dbca刪除故障節點實例。

（3）更新集群列表

保留節點更新GRID_HOME集群列表，在保留的節點執行：

更新ORACLE_HOME集群列表，在保留節點上執行：

（4）刪除節點

在任一保留的節點上刪除tjhyrac2節點，執行以下操作：

（5）驗證

驗證tjhyrac2節點被刪除，在任一保留的節點上執行操作：

（6）刪除VIP地址

刪除tjhyrac2節點VIP地址。通過命令crsctl status res -t檢查，如果VIP2還在，需要刪除VIP，命令如下：

3.2.2 添加節點

3.2.2.1 添加節點前檢驗

在保留節點使用grid用戶進行添加節點前檢驗。

如果報錯：無法從節點XXX檢索exectask，請檢查共享。

如果無法共享，執行：

3.2.2.2 加入集群

將新增節點加入集群，在D:>Grid_homeaddnode下執行：

添加節點后遇到報錯：“INS-30132 RUNNING ADDNODE.BAT DUE TO CVU CHECKFRAMEWORKSETUP() API ERROR”，其原因是由于觸發BUG:24522899，導致無法添加節點，具體解決辦法如下：

（1）修改相關文件

在執行添加命令的節點，修改$GRID_HOMEcvcvdataadmin.xml文件，將下面一段的內容替換上面一段的內容：

（2）刪除臨時文件

在需要添加的節點上，到%temp%目錄下刪除CVU_12.1.0.2.0_。

（3）替換文件cvu.jar

在以下路徑檢查cvu.jar文件的大小和時間是否相同。如果不同，在所有節點上復制和替換最新的文件cvu.jar到另外的目錄下。

（4）重新運行addNode.bat

此時運行會遇到the error：INS-40394，執行如下步驟：

a.取消OUI Window；

b.在運行addNode.bat的節點編輯HOSTS注釋本地主機的VIP地址和要添加的節點的VIP地址；

c.重新運行addNode.bat；

d.添加完成后放開本地主機的VIP地址和要添加節點的VIP地址的注釋。

e.按默認執行。添加節點過程如圖3所示。

圖3 Oracle12C添加節點過程圖

3.2.3 配置GRID

根據提示執行操作，在新添加的節點上運行如下命令：

D:appgrid12.1.0gridcrsconfig>gridconfig.bat執行完成后，點擊確定。

3.2.4 安裝Oracle軟件

在節點1 Oracle軟件安裝路徑下進入目錄addnode執行：

addnode.bat "CLUSTER_NEW_NODES={tjhyrac2}"

按默認執行即可。

3.2.5 啟動實例

如果添加節點的實例未啟動，可在任一節點手動啟動節點2的實例。

srvctl start instance -d oratjhy -n tjhyrac2。

3.2.6 創建初始化文件

如果發現所添加節點的初始化文件未創建，可手動創建initoratjhy2.ora（根據該節點實際的實例名來定），并從節點1的初始化文件，復制如下內容，添加到initoratjhy2.ora。

SPFILE='+DATA/oratjhy/spfileoratjhy.ora'

同理，配置監聽參數文件和數據庫口令文件。

3.2.7 創建OraMTS Service服務

在%ORACLE_HOME%in下執行命令如下：oramtsctl.exe -new -host tjhyrac2至此，節點2恢復工作全部完成。

4 方案實施效果

為了確保集群運行安全穩定，方案實施后，我們針對RAC的原理及特性，對刪除、添加節點后RAC的有效性進行驗證。

4.1 RAC有效性測試-重啟服務器

測試目的：驗證Oracle RAC中的一個節點發生故障后，另一個節點能否自動接管交易處理，以及故障恢復后節點處理能力能否恢復正常。

測試步驟：（1）利用客戶端連接節點2，執行事先準備好的SQL腳本，同時將節點2服務器重啟模擬節點故障；（2）繼續穩定運行10 min；（3）故障節點開始恢復，同時啟動該節點上的Oracle 實例；（4）繼續穩定運行10 min。

測試結果：（1）步驟1后被測試數據庫RAC切換成功，切換過程中，交易響應時間延長；（2）切換后VIP漂移到另一個實例，交易在1 min內能夠恢復正常；（3）步驟3后故障節點恢復后，VIP重新漂回，受理交易恢復正常。

測試結果符合預期，測試結果通過。

4.2 RAC有效性測試-停實例

測試目的：考察系統在一定并發下,手動異常停止節點2數據庫實例后，另一個數據庫實例能否自動接管交易處理，以及故障恢復后節點處理能力能否恢復正常。

測試步驟：（1）手動（shutdown abort）停止節點2數據庫實例，場景持續運行5 min；（2）啟動停止的數據庫實例，場景持續運行5 min。

測試結果：（1）手動停止數據庫實例后，另一節點實例會很快（2 s內）接收請求（Failover機制生效）；（2）步驟2重啟停止節點實例后，受理交易正常。

實際測試結果符合預期，測試結果通過。

4.3 RAC有效性測試-心跳網絡異常

測試目的：驗證數據庫RAC中的心跳網絡異常后（主備網卡置down），另一節點能否自動接管交易處理，故障恢復后節點處理能力能否恢復正常。

測試步驟：（1）將節點1的網卡置down，觀察交易處理、響應時間及各主機資源情況，驗證VIP是否可以正常切換；（2）恢復該節點心跳主備網卡，重啟CRS，交易穩定運行5 min，觀察被測試系統交易恢復情況。

測試結果：（1）宕掉節點2的心跳主備網卡，由于RAC集群由4節點組成，不會出現腦裂，節點2實例重啟，CRS重啟，節點2的VIP漂移到節點1；交易切換至其它節點；（2）節點2心跳主備網卡故障恢復后，VIP回漂，數據庫可正常啟動并加入RAC，交易不受影響。

實際測試結果符合預期，測試結果通過。

從以上3個場景可以看出：如果其中某個節點發生問題，都實現了無用戶干預的自動故障切換，通過損壞節點的恢復，提升了數據庫的可靠性[11]。

5 結束語

通過該方案的研究與相關難點問題的解決，成功實現了Windows平臺下Oracle12C RAC集群在線恢復損壞節點，驗證了Oracle RAC的易伸縮性，滿足了核心系統自身的調整需要，也為其他平臺下的節點恢復提供了參考。雖然RAC有著眾多的優點，但是由于部署一套RAC會涉及到服務器、操作系統、存儲設備、HBA卡等多方面的技術，且從實現上比單實例數據庫更復雜，RAC自身也存在不少Bug，今后，還將對如何進一步提高RAC的穩定性、兼容性及性能調優等方面進行深入研究，為生產系統運維及開發提供更好的技術支撐。