ORACLE RAC的一些基本理論知識

一 . Oracle RAC 的發展歷程

1. Oracle Parallel Server (OPS)

早期階段：Oracle 6 和 7
- Oracle Parallel Server（OPS）是 Oracle RAC 的前身。
- 通過多個實例并行訪問同一個數據庫來提高性能。
- 共享磁盤架構，利用分布式鎖管理（DLM）來管理并發訪問。
- OPS 存在復雜的鎖定和同步問題，限制了其廣泛應用。

2. Oracle 8i 和 9i

Oracle 8i
- 引入了對集群數據庫的基本支持，但 OPS 的并行處理和一致性問題仍然存在。
Oracle 9i (2001)
- 正式引入 Oracle RAC，取代了 OPS。
- 改進的全局緩存服務（GCS）和全局鎖管理（GLM）解決了 OPS 的一致性問題。
- 高可用性和故障轉移功能得到顯著增強。
- 通過 Cache Fusion 技術實現節點之間的數據塊傳輸，提高了性能和可擴展性。

3. Oracle 10g

Oracle 10g Release 1 (2003)
- 引入 Automatic Storage Management（ASM）簡化存儲管理。
- 改進的集群管理功能，包括 Oracle Clusterware。
- 提供更好的負載均衡和故障檢測機制。
Oracle 10g Release 2
- 增強了 RAC 的穩定性和性能。
- 引入更高級的負載均衡算法。

4. Oracle 11g

Oracle 11g Release 1 (2007)
- 加強了自動化管理功能，包括自動內存管理和自動 SQL 調優。
- 改進了高可用性功能，如 Data Guard 與 RAC 的集成。
Oracle 11g Release 2
- 引入 Oracle Grid Infrastructure，整合了 Clusterware 和 ASM。
- 改進的 Rolling Upgrade 功能，減少升級過程中的停機時間。
- 增強了對虛擬化和云環境的支持。

5. Oracle 12c

Oracle 12c Release 1 (2013)
- 引入多租戶架構（Multitenant Architecture），支持容器數據庫（CDB）和可插拔數據庫（PDB）。
- 改進了集群管理和自動化功能，簡化了部署和管理。
- 增強了對云計算和大數據環境的支持。
Oracle 12c Release 2 (2016)
- 提供更好的性能和可擴展性。
- 引入新的存儲選項和改進的備份恢復功能。

6. Oracle 18c 和 19c

Oracle 18c (2018)
- 強調自動化和智能化管理，進一步簡化數據庫管理任務。
- 引入更多的云服務集成功能。
Oracle 19c (2019)
- 提供長期支持（Long Term Support），強調穩定性和性能優化。
- 增強的自動化診斷和修復功能。

7. Oracle 21c 和 23c

Oracle 21c (2021)
- 支持容器數據庫（CDB）架構。
- 提供更多的自動化管理和 AI 驅動的功能。
- 增強對混合云和多云環境的支持。

Oracle RAC 從9i正式引入至今已經發展了20多年，如果說是關系型數據庫中最成功，最穩定的高可用架構應該沒有異議，不過從11g之后Oracle RAC就沒有太多革命性的創新，所以基本的理論概念基本沒有變化，下面簡單一下 Oracle Rac的一些基本概念知識（基于ORACLE 10G，不過基本沒差別）

二.RAC相關理論知識

2.1 并發控制

在集群環境中，關鍵數據通常是共享存放的，比如放在共享磁盤上。而各個節點的對數據有相同的訪問權限，這時就必須有某種機制能夠控制節點對數據的訪問。Oracle?RAC是利用DLM(Distribute Lock Management)?機制來進行多個實例間的并發控制。

2.2?健忘癥(Amnesia)

集群環境配置文件不是集中存放的，而是每個節點都有一個本地副本，在集群正常運行時，用戶可以在任何節點更改集群的配置，并且這種更改會自動同步到其他節點。

有一種特殊情況：節點A?正常關閉，在節點B上修改配置，關閉節點B，啟動節點A。這種情況下，修改的配置文件是丟失的，就是所謂的健忘癥。

2.3?腦裂(Split Brain)

在集群中，節點間通過某種機制(心跳)了解彼此的健康狀態，以確保各節點協調工作。假設只有"心跳"出現問題，各個節點還在正常運行，這時，每個節點都認為其他的節點宕機了，自己是整個集群環境中的"唯一建在者"，自己應該獲得整個集群的"控制權"。在集群環境中，存儲設備都是共享的，這就意味著數據災難，這種情況就是"腦裂"

解決這個問題的通常辦法是使用投票算法(Quorum Algorithm).?它的算法機理如下：

集群中各個節點需要心跳機制來通報彼此的"健康狀態"，假設每收到一個節點的"通報"代表一票。對于三個節點的集群，正常運行時，每個節點都會有3票。當節點A心跳出現故障但節點A還在運行，這時整個集群就會分裂成2個小的partition。節點A是一個，剩下的2個是一個。這是必須剔除一個?partition才能保障集群的健康運行。

對于有3個節點的集群，?A?心跳出現問題后，?B?和?C?是一個partion，有2票，?A只有1票。按照投票算法，?B?和C?組成的集群獲得控制權，?A?被剔除。

如果只有2個節點，投票算法就失效了。因為每個節點上都只有1票。這時就需要引入第三個設備：Quorum Device.?Quorum Device?通常采用是共享磁盤，這個磁盤也叫作Quorum disk。這個?Quorum Disk?也代表一票。當2個節點的心跳出現問題時，?2個節點同時去爭取Quorum Disk?這一票，最早到達的請求被最先滿足。故最先獲得Quorum Disk的節點就獲得2票。另一個節點就會被剔除。

2.4 IO?隔離(Fencing)

當集群系統出現"腦裂"問題的時候，我們可以通過"投票算法"來解決誰獲得集群控制權的問題。但是這樣是不夠的，我們還必須保證被趕出去的節點不能操作共享數據。?這就是IO Fencing?要解決的問題。

IO Fencing實現有硬件和軟件2種方式：

軟件方式：對于支持SCSI Reserve/Release?命令的存儲設備，可以用SG命令來實現。正常的節點使用SCSI Reserve命令"?鎖住"存儲設備，故障節點發現存儲設備被鎖住后，就知道自己被趕出了集群，也就是說自己出現了異常情況，就要自己進行重啟，以恢復到正常狀態。這個機制也叫做?Sicide(自殺).?Sun?和Veritas?使用的就是這種機制。

硬件方式：STONITH(Shoot The Other Node in the Head)，這種方式直接操作電源開關，當一個節點發生故障時，另一個節點如果能偵測到，就會通過串口發出命令，控制故障節點的電源開關，通過暫時斷電，再上電的方式使故障節點被重啟動，這種方式需要硬件支持。

三?RAC?集群

3.1 Clusterware

在單機環境下，Oracle是運行在OS Kernel?之上的。OS Kernel負責管理硬件設備，并提供硬件訪問接口。Oracle?不會直接操作硬件，而是由OS Kernel代替它來完成對硬件的調用請求。

在集群環境下，存儲設備是共享的。OS Kernel?的設計都是針對單機的，只能控制單機上多個進程間的訪問。如果還依賴OS Kernel的服務，就無法保證多個主機間的協調工作。這時就需要引入額外的控制機制，在RAC中，這個機制就是位于Oracle?和?OS Kernel?之間的?Clusterware，它會在OS Kernel之前截獲請求，然后和其他結點上的Clusterware協商，最終完成上層的請求。

在?Oracle10G之前，RAC?所需要的集群件依賴于硬件廠商，比如SUN,HP,Veritas.?從Oracle 10.1版本中，Oracle?推出了自己的集群產品. Cluster Ready Service(CRS),從此RAC?不再依賴于任何廠商的集群軟件。在?Oracle 10.2版本中，這個產品改名為：Oracle Clusterware。

所以我們可以看出，在整個RAC?集群中，實際上有2個集群環境的存在，一個是由Clusterware?軟件組成的集群，另一個是由Database?組成的集群。

3.2 Clusterware?組成

Oracle Cluster?是一個單獨的安裝包，安裝后，在每個節點上的Oracle Clusterware?會自動啟動。?Oracle Clusterware的運行環境由2個磁盤文件(OCR,Voting Disk)，若干進程和網絡元素組成。

3.2.1?磁盤文件:

Clusterware?在?運行期間需要兩個文件：OCR和Voting Disk.?這2個文件必須存放在共享存儲上。?OCR?用于解決健忘問題，Voting Disk?用于?解決腦裂問題。?Oracle?建議使用裸設備來存放這2個文件，每個文件創建一個裸設備，每個裸設備分配100M左右的空間就夠了。

3.2.1.1 OCR

健忘問題是由于每個節點都有配置信息的拷貝，修改節點的配置信息不同步引起的。?Oracle?采用的解決方法就是把這個配置文件放在共享的存儲上，這個文件就是OCR Disk。

OCR?中保存整個集群的配置信息，配置信息以"Key-Value"?的形式保存其中。在Oracle10g以前，這個文件叫作?Server Manageability Repository(SRVM).?在Oracle10g，這部分內容被重新設計，并重名為OCR.在?Oracle Clusterware?安裝的過程中，安裝程序會提示用戶指定OCR位置。并且用戶指定的這個位置會被記錄在/etc/oracle /ocr.Loc(Linux System)?或者/var/opt/oracle/ocr.Loc(Solaris System)文件中。而在?Oracle 9i RAC中，對等的是srvConfig.Loc文件。?Oracle Clusterware在啟動時會根據這里面的內容從指定位置讀入OCR?內容。

1). OCR key

整個OCR?的信息是樹形結構，有3個大分支。分別是SYSTEM,DATABASE?和CRS。每個分支下面又有許多小分支。這些記錄的信息只能由root用戶修改。

2)OCR process

Oracle Clusterware?在OCR中存放集群配置信息，故OCR?的內容非常的重要，所有對OCR的操作必須確保OCR?內容完整性，所以在ORACLE Clusterware運行過程中，并不是所有結點都能操作OCR Disk.

在每個節點的內存中都有一份OCR內容的拷貝，這份拷貝叫做OCR Cache。每個結點都有一個OCR Process?來讀寫OCR Cache，但只有一個節點的OCR process能讀寫OCR Disk中的內容，這個節點叫作OCR Master結點。這個節點的OCR process?負責更新本地和其他節點的OCR Cache內容。

所有需要OCR內容的其他進程，比如OCSSD,EVM等都叫作Client Process，這些進程不會直接訪問OCR Cache，而是OCR Process發送請求，借助OCR Process獲得內容，如果想要修改OCR?內容，也要由該節點的OCR Process像?Master node?的OCR process提交申請，由Master OCR Process完成物理讀寫，并同步所有節點OCR Cache?中的內容。

3.2.1.2?? Voting Disk

Voting Disk?這個文件主要用于記錄節點成員狀態，在出現腦裂時，決定哪個Partion獲得控制權，其他的Partion必須從集群中剔除。在安裝?Clusterware時也會提示指定這個位置。安裝完成后可以通過如下命令來查看Voting Disk位置。

$crsctl query css votedisk##  STATE    File Universal Id                File Name Disk group--  -----    -----------------                --------- --------- 1. ONLINE   ac0d65877b454fxxxxxxcx1c936ef316 (/dev/mapper/crs1) [CRS]?2.?ONLINE???37e617cd5c254f5xxxxxxcff5b2c381b?(/dev/mapper/crs2)?[CRS] 3. ONLINE   5140d0509b764fxxxxxxc37ea369e6b7 (/dev/mapper/crs3) [CRS]Located 3 voting disk(s).

3.2.2?Clusterware?后臺進程

Clusterware?由若干進程組成，其中最重要的3個是：CRSD,CSSD,EVMD.在安裝clusterware的最后階段，會要求在每個節點執行root.sh?腳本，這個腳本會在/etc/inittab?文件的最后把這3個進程加入啟動項，這樣以后每次系統啟動時，Clusterware?也會自動啟動，其中?EVMD和CRSD?兩個進程如果出現異常，則系統會自動重啟這兩個進程，如果是CSSD?進程異常，系統會立即重啟。

1). OCSSD

OCSSD?這個進程是Clusterware最關鍵的進程，如果這個進程出現異常，會導致系統重啟，這個進程提供?CSS(Cluster Synchronization Service)服務。CSS?服務通過多種心跳機制實時監控集群狀態，提供腦裂保護等基礎集群服務功能。

CSS?服務有2種心跳機制：一種是通過私有網絡的Network Heartbeat，另一種是通過Voting Disk的Disk Heartbeat.

這?2種心跳都有最大延時，對于Disk Heartbeat，這個延時叫作IOT (I/O Timeout);對于?Network Heartbeat,?這個延時叫MC(Misscount)。這2個參數都以秒為單位，缺省時IOT大于MC，在默認情況下，這2個參數是Oracle?自動判定的，并且不建議調整。可以通過如下命令來查看參數值：

crsctl?get?css?disktimeoutCRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services.crsctl?get?css?misscountCRS-4678: Successful get misscount 30 for Cluster Synchronization Services.

注：除了Clusterware?需要這個進程，在單節點環境中如果使用了ASM，也需要這個進程；這個進程用于支持ASM Instance?和?RDBMS Instance之間的通信。如果在使用了ASM的節點上安裝RAC，會遇到一個問題：RAC節點要求只有一個OCSSD進程，并且應該是運行$CRS_HOME目錄下的，這時就需要先停止ASM，并通過$ORACLE_HOME/bin/localcfig.Sh delete?刪除之前的inittab?條目。之前安裝ASM時，也使用這個腳本來啟動OCSSD：?$ORACLE_HOME/bin /localconfig.Sh add.

2). CRSD

CRSD是實現"高可用性(HA)"的主要進程，它提供的服務叫做CRS(Cluster Ready Service)?服務。

Oracle Clusterware是位于集群層的組件，它要為應用層資源(CRS Resource)?提供"高可用"，所以，Oracle Clusterware?必須監控這些資源，并在這些資源運行異常時進行干預，包括關閉，重啟進程或者轉移服務。CRSD進程提供的就是這些服務。

所有需要高可用性的組件，都會在安裝配置的時候，以CRS Resource的形式登記到OCR中，而CRSD進程就是根據OCR中的內容，決定監控哪些進程，如何監控，出現問題時又如何解決。也就是說，CRSD?進程負責監控CRS Resource?的運行狀態，并要啟動，停止，監控，Failover這些資源。默認情況下，CRS?會自動嘗試重啟資源5次，如果還是失敗，則放棄嘗試。

CRS Resource?包括GSD(Global Serveice Daemon),ONS(Oracle Notification Service),VIP, Database, Instance?和?Service.?這些資源被分成2類：

GSD，ONS,VIP?和?Listener?屬于Noteapps類

Database，Instance?和Service?屬于?Database-Related Resource?類。

我們可以這樣理解：?Nodeapps?就是說每個節點只需要一個就夠了，比如每個節點只有一個Listener，而Database- Related Resource?就是說這些資源和數據庫有關，不受節點的限制，比如一個節點可以有多個實例，每個實例可以有多個Service。

GSD，ONS,VIP?這3個服務是在安裝Clusterware的最后，執行VIPCA?時創建并登記到OCR中的。而Database，?Listener，?Instance?和Service?是在各自的配置過程中自動或者手動登記到OCR中的。

3). EVMD

EVMD?這個進程負責發布CRS?產生的各種事件(Event).?這些Event可以通過2種方式發布給客戶：ONS和?Callout Script.?用戶可以自定義回調腳本，放在特定的目錄下，這樣當有某些事件發生時，EVMD會自動掃描該目錄，并調用用戶的腳本，這種調用是通過racgevt進程來完成的。

EVMD?進程除了復雜發布事件之外，它還是CRSD?和CSSD?兩個進程之間的橋梁。?CRS?和CSS?兩個服務之前的通信就是通過EVMD?進程完成的。

4). RACGIMON

RACGIMON?這個進程負責檢查數據庫健康狀態，負責Service的啟動，停止，故障轉移(Failover)。這個進程會建立到數據庫的持久連接，定期檢查SGA中的特定信息，該信息由PMON?進程定時更新。

5). OPROCD

OPROCD?這個進程也叫做?Process Monitor Daemon.?如果在非Linux?平臺上，并且沒有使用第三方的集群軟件時，就會看到這個進程。這個進程用來檢查節點的Processor Hang(CPU?掛起),?如果調度時間超過1.5秒，就會認為CPU?工作異常，會重啟節點。也就是說這個進程提供?"IO?隔離"?的功能。從其在Windows?平臺上的服務名：?OraFnceService?也可以看出它的功能。而在?Linux?平臺上，是利用Hangcheck-timer?模塊來實現"IO?隔離"的。