1、什麼是cluster

一個cluster是由兩個或是多個獨立的、通過網路連線的servers組成的。幾個硬體供應商多年以來提供了Cluster效能的各種需求。一些Clusters僅僅為了提供高可用性的，在當前活動的node發生故障時轉移到次節點node。另一些是為了提供分散式的連線、工作的可擴充套件性。另一個Cluster的共同特點是，對於一個應用程式，它可以看做是一個單獨的server。同樣，管理幾個servers應該儘可能像管理一個server一樣簡單。Cluster管理器軟體提供了這種功能。

如果是single server的nodes，檔案必須儲存在其各自node能訪問的位置。存在有幾個不同拓撲結構來解決資料訪問的問題，這主要依賴於Cluster設計的主要目標。

相互連線時一個物理的網路連線，作為每個Cluster節點直接的互動通訊。

簡而言之，一個Cluster就是一組獨立的servers，它們共同協作，組成一個single system。

2、什麼是Oracle real Application Cluster(RAC)

RAC是一個軟體可以使你通過執行多個依賴相同Database的Instance，使用Cluster硬體。資料庫files被存放在物理或是邏輯上連線每個節點的磁碟上。以便於每個活動的Instance都可以對files進行讀寫操作。

RAC軟體管理著資料的訪問。所以更改操作在Instances之間是被相互協調的，並且每個Instance看到的資訊和資料映象都是一致的。

通過RAC結構，可以獲得冗餘，從而使得即使在一個系統crash或是不可訪問時，應用程式也可通過其他Instance訪問Database。

3、為啥使用RAC

RAC可以高度利用標準的Cluster，降低模組servers成本。

RAC自動的提供了服務的工作量管理。應用程式的服務可以被分組或分類，組成商業元件完成應用工作任務。RAC中的服務可以是持續的、不間斷的Database操作，併為多Instance上的多個服務提供支援。可以設計services到一個或多個Instance上執行，並且交替Instances可以用於備份Instances。如果主Instance失敗，Oracle會將services從失敗的Instance節點移動到活動的可替代的Instance上。Oracle也會自動的通過連線進行資料裝載的平衡。

RAC利用多個廉價的computers共同提供Database的服務，就像一個大的computer一樣，服務於只有大規模SMP才能提供的各種應用。

RAC是基於共享磁碟結構的，在需求上可以增加或縮減，而不需要人為的在Cluster中進行資料的分隔。並且RAC可以簡單的增加、移出Cluster中的servers。

4、Clusters和可擴充套件性

如果使用對稱多處理(symmetric multiprocessing SMP)機制能夠對應用程式提供透明的服務，則應該使用RAC也可以得到同樣的效果，而不需要進行應用程式程式碼的任何改動。

當一個節點發生失敗，RAC可以排除該Database Instance和node本身，從而保證Database的完整。

下面是一些可擴充套件性的例子：

* 允許更多併發的批處理。

* 允許更大程度的併發執行。

* 在OLTP系統中可以是連線的使用者大增。

1)可擴充套件性的層次：主要有四個層次

* hardware 的可擴充套件性：相互連線性是它的關鍵，這一般依賴於較高的頻寬和較低的延遲。

* OS的可擴充套件性：在OS中，同步方法可以決定系統的可擴充套件性。在一些情況下，硬體的潛在可擴充套件性會因為OS無力併發維持請求的多個資源而被丟失。

* Database管理系統的可擴充套件性：在併發結構中的一個關鍵因素是併發是由內部影響的還是外部程序影響的。此問題的答案影響了同步的機制。

* 應用層次上的可擴充套件性：應用程式必須被明確的設計為可擴充套件的。當系統中如果多數情況下，每個session都在更新相同的data，則可能產生瓶頸。這不僅是指RAC，對於single-instance系統也是一樣。

需要明確的是，如果任何一個層次沒有達到可擴充套件性，不管其他層次可擴充套件性多強，併發的Cluster程序都可能失敗。可擴充套件性不足的典型原因是共享資源的訪問。這使得併發的操作在此瓶頸上序列化執行。這不僅僅是RAC中的侷限，而是所有結構中的侷限性。

2)scaleup和speedup

* scaleup是工作量和資源都成比例增加時能維持相同效能水平的能力(相應時間)

Scaleup=(volume parallel)/(volume original)–time for ipc

* speedup是指通過增加資源的數量完成固定的工作量，獲得執行時間成比例的縮減的效果。

Speedup=(time original)/(time parallel)–time for ipc

其中，ipc是程序間通訊的簡寫——interprocess communication

RAC Architecture and Concepts

1、RAC軟體原理

在一個RAC Instance中，會見到一些普通Instance中不存在的後臺程序，它們主要是用於維持Database在每個Instance中的一致性。管理全域性資源，具體如下：

* LMON：全域性佇列服務監控程序——Global Enqueue Service Monitor

* LMD0：全域性佇列服務守護程序——Global Enqueue Service Daemon

* LMSx：全域性緩衝服務程序，x可以從0到j——Global Cache Service Processes

* LCK0：鎖程序——Lock process

* DIAG：診斷程序——Diagnosibility process

在Cluster層，可以找到Cluster Ready Services軟體的主要程序，它們在所有平臺上提供標準的Cluster介面，並實現高可用性的操作。在每個Cluster node上都可以看到如下的程序：

* CRSD和RACGIMON：用於高可用性操作的引擎。

* OCSSD：提供成員節點和服務組的訪問

* EVMD：事件檢測程序，由oracle使用者執行管理

* OPROCD：Cluster的監控程序

此外還存在幾個工具用於管理Cluster中全域性層次上的各種資源。這些資源是ASM Instance、RAC Database、Services和CRS應用節點。本書中涉及的工具主要有Server Control(SRVCTL)、DBCA和Enterprise Manager。

2、RAC軟體儲存原理

Oracle10g的RAC安裝分為兩個階段。第一階段是安裝CRS，其次是安裝帶有RAC元件的Database軟體並建立Cluster資料庫。CRS軟體使用的Oracle home必須不同於RAC軟體使用的home。儘管可以將Cluster中CRS和RAC軟體通過使用Cluster檔案系統共享儲存，但是軟體總是按一定規則安裝在每個節點的本地檔案系統中。這支援線上補丁的升級，並消除了單節點軟體造成的失敗。另外有兩個必須儲存在共享的儲存裝置中：

* voting file：其本質上是用於Cluster synchronization Services守護程序進行節點資訊的監控。大小約為20MB。

* Oracle Cluster Registry(OCR)檔案：也是CRS關鍵的組成部分。用於維護在Cluster中高可用性元件的資訊。例如，Cluster節點列表，Cluster資料庫Instance到節點的對映和CRS應用資源的列表(如Services、虛擬內部連結協議地址等)。此檔案是通過SRVCTL類似的管理工具自動維護的。其大小約100MB。

voting file和OCR file是不能被儲存在ASM中的，因為它們必須在任何Oracle Instance啟動前就可以被訪問。並且，兩者必須是在冗餘的、可靠的儲存裝置中存放，如RAID。推薦最好的做法是將這些檔案放在裸磁碟上。

3、OCR的結構

Cluster的配置資訊是在OCR中維護的。OCR依賴分散式的共享快取結構用於優化關於Cluster知識庫的查詢。在Cluster中的每個節點都通過OCR程序訪問OCR快取在其記憶體中維護著一個副本。事實上在Cluster中，只有一個OCR程序對共享儲存中的OCR進行讀寫操作。此程序負責重新整理(refresh)其自己擁有的本地快取以及Cluster中其他節點的OCR cache。對於涉及到Cluster知識庫的訪問，OCR客戶端直接訪問本地OCR程序。當客戶端需要更新OCR時，它們將通過本地OCR程序與那個扮演讀寫OCR檔案的程序進行互動。

OCR客戶端應用有：Oracle通用安裝器(OUI)、SRVCTL、企業管理器(EM)、DBCA、DBUA、NetCA和虛擬網路協議助理(VIPCA)。此外，OCR維護管理著CRS內部中定義的各種應用程式的資源的依賴和狀態資訊，特別是Database、Instance、Services和節點的應用程式。

配置檔案的名字是ocr.loc，並且配置檔案變數是ocrconfig_loc。Cluster 知識庫的位置是不受限於裸裝置的。可以將OCR放置在由Cluster file system管理的共享儲存裝置上。

note：OCR也可用於在ASM的單Instance中作為配置檔案，每個節點有一個OCR。

4、RAC Database儲存原理

與single-Instance Oracle的儲存方式最主要的不同之處在於RAC儲存必須將所有RAC中資料檔案存放在共享裝置中(裸裝置或是Cluster檔案系統)以便於訪問相同Database的Instance能夠共享。必須為每個Instance建立至少兩個redo log組，並且所有的redo log組必須也儲存在共享裝置中，從而為了crash恢復的目的。每個Instance的線上redo log groups被稱作一個Instance的線上redo 執行緒。

此外，必須為每個Instance建立一個共享的undo表空間用於Oracle推薦的undo自動管理特點。每個undo表空間必須是對所有Instance共享的，主要用於恢復的目的。

歸檔日誌不能被存放在裸裝置上，因為其命名是自動產生的，並且每個是不一致的。因此需要儲存在一個檔案系統中。如果使用Cluster file system(CFS)，則可以在任何時間在任何node上訪問這些歸檔檔案。如果沒有使用CFS，就不得不使其他Cluster成員在恢復時那些歸檔日誌是可用的，例如通過網路檔案系統(NFS)來實現。如果使用推薦的flash recovery area特性，則其必須被儲存在共享目錄下，以便於所有的Instance能夠訪問。(共享目錄可以是一個ASM磁碟組，或是一個CFS)。

5、RAC和共享儲存技術

儲存是網格技術中的關鍵組成部分。傳統上，儲存都直接依附在每個Server(directly attached to each inpidual Server DAS)上。在過去的幾年來，更靈活的儲存出現並得到應用，主要是通過儲存空間網路或是正規的乙太網來實現訪問。這些新的儲存方式使得多個Servers訪問相同的磁碟集合成為可能，在分散式環境中，可以獲得簡單的存取。

storage area network(SAN)代表了資料儲存技術在這一點的演進。傳統上，C/S系統中，資料被儲存在Server內部或是依附它的裝置中。隨後，進入了network attached storage(NAS)階段，這使得儲存裝置與Server和直接連線它們的網路向分離。它在SAN遵循的原則進一步允許儲存裝置存在於各自的網路中，並直接通過高速的媒介進行交換。使用者可以通過Server系統對儲存裝置的資料進行訪問，Server 系統與本地網路(LAN)和SAN相互連線。

檔案系統的選擇是RAC的關鍵。傳統的檔案系統不支援多系統的並行掛載。因此，必須將檔案儲存在沒有任何檔案系統的裸卷標或是支援多系統併發訪問的檔案系統中。

因此，三個主要的方法用於RAC的共享儲存有：

* 裸卷標：既是一些直接附加的裸裝置，需要用於儲存，並以block模式程序操作。

* Cluster file system：也需要以block模式程序存取。一個或多個Cluster file 系統可以被用於儲存所有的RAC檔案。

* 自動儲存管理(ASM)：對於Oracle Database files，ASM是一個輕便的、專用的、最佳化的Cluster file system。

6、Oracle Cluster file system

Oracle Cluster file system(OCFS)是一個共享檔案系統，專門為Oracle RAC設計。OCFS排除了Oracle Database files被連線到邏輯磁碟上的需要，並使得所有的節點共享一個ORACLE Home，而不需每個node在本地有一個副本。OCFS卷標可以橫跨一個或多共享disks，用於冗餘和效能的增強。

下面時可放入OCFS中的檔案類表：

* Oracle software的安裝檔案：在10g中，此設定只在windows 2000中支援。說是後面的版本會提供在Linux中的支援，但我還沒具體看。

* Oracle 檔案(控制檔案、資料檔案、redo logs檔案，bfiles等)

* 共享配置檔案(spfile)

* 在Oracle執行期間，由Oracle建立的檔案。

* voting和OCR檔案

Oracle Cluster file system對開發人員和使用者時免費的。可從官方網站下載。

7、自動儲存管理(ASM)

是10g的新特性。它提供了一個縱向的統一管理的檔案系統和卷標管理器，專門用於建立Oracle Database 檔案。ASM可以提供單個SMP機器的管理或是貫穿多個Oracle RAC的Cluster節點。

ASM無需再手動調節I/O，會自動的分配 I/O 負載到所有的可用資源中，從而優化效能。通過允許增加Database大小而不需shutdown資料庫來調節儲存分配，來輔助DBA管理動態資料庫環境。

ASM可以維護資料的冗餘備份，從而提高故障的容錯。它也可以被安裝到可靠的儲存機制中。

8、選擇RAW或CFS

* CFS的優點：對於RAC的安裝和管理非常簡單;對RAC使用Oracle managed files(OMF);single Oracle軟體安裝;在Oracle data files上可以自動擴充套件;當物理節點失敗時，對歸檔日誌的統一訪問。

* 裸裝置的使用：一般會用於CFS不可用或是不被Oracle支援的情況下;它提供了最好的效能，不需要在Oracle和磁碟之間的中間層;如果空間被耗盡，裸裝置上的自動擴充套件將失敗;ASM、邏輯儲存管理器或是邏輯卷標管理其可以簡化裸裝置的工作，它們也允許載入空間到線上的裸裝置上，可為裸裝置建立名字，從而便於管理。

9、RAC的典型Cluster棧

在Cluster中的每個節點都需要一個被支援的相互連線的軟體協議來支援內部Instance的互動，同時需要TCP/IP支援CRS的輪詢。所有的UNIX平臺在千兆乙太網上使用user datagram protocol(UDP)作為主要的協議並進行RAC內部Instance 的IPC互動。其他支援的特有協議包括用於SCI和Sunfire的連線互動的遠端共享記憶體協議和超文字協議，用於超光纖互動。在任何情況下，互動必須能被平臺的Oracle所辨識。

使用Oracle clusterware，可以降低安裝並支援併發症。但如果使用者使用非以太互動，或開發了依賴clusterware的應用程式在RAC上，可能需要vendor clusterware。

同互動連線一樣，共享儲存方案必須被當前平臺的Oracle所辨識。如果在目標平臺上，CFS可用，Database area和flash recovery area都可以被建立到CFS或ASM上。如果在目標平臺上，CFS不可用，則Database area可以建立在ASM或是裸裝置上(需要卷標管理器)並且flash recovery area必須被建立在ASM中。

10、RAC certification Matrix：它設計用於處理任何認證問題。可以使用matrix回答任何RAC相關的認證問題。具體使用步驟如下：

* 連線並登陸 https://metalink.oracle.com

* 點選選單欄的“certify and availability”按鈕

* 點選“view certifications by product”連線

* 選擇RAC

* 選擇正確的平臺

11、必要的全域性資源

一個single-Instance環境，鎖座標通向一個共享的資源就像表中的一行。lock避免了兩個程序同事修改相同的資源。

在RAC環境中，內部節點的同步時關鍵，因為它維持著不同節點中各自程序的一致性，避免其在同時修改相同的資源資料。內部節點的同步確保每個Instance看到buffer cache中block的最近的版本。上圖中顯示了當不存在加鎖的情況。

1)全域性資源的協調

cluster操作要求在所有Instance中對控制共享資源的訪問進行同步。RAC使用Global Resource Directory來記錄cluster Database中資源的使用資訊。Global Cache Service(GCS)和Global Enqueue Service(GES)管理GRD中的資訊。

每個Instance在其本地的SGA中維護GRD的一部分。GCS和GES指定一個Instance管理特殊資源的所有資訊，它被稱為資源的master。每個Instance都知道resource的Instance masters。

維護RAC的活動中的cache的依附性(cache coherency)是非常重要的。所謂cache coherency是保持在不同Oracle Instances中的多個block版本的一致性的技術。GCS通過所謂的cache融合演算法來實現cache coherency。

GES管理所有非cache 融合演算法的內部Instance資源操作和Oracle入隊機制的狀態軌跡。GES主要的控制的資源是字典cache locks和library cache locks。同時，它還對所有死鎖敏感的佇列和資源起到死鎖檢測的作用。

2)Global cache coordination例項

假設某data block被第一個節點修改，成為髒資料。並且在clusterwide中，只有一個block copy版本，其內容用SCN號代替了。則具體的步驟如下：

① 第二個Instance檢視修改該block，向GCS提出請求。

② GCS向block的holder(持有者)提交請求。在此，第一個Instance就是holder。

③ 第一個Instance接到訊息，並將block傳送給第二個Instance。第一個Instance儲存髒buffer用於恢復的目的。block的髒映象被稱作block的past image。一個past image block將不能進一步被改變。

④收到block後，第二個Instance通知GCS，告知已經holds該block。

3)write to disk coordination：example

在cluster結構中的Instances中的caches中，可能存在同一個block的不同的修改版本。由GCS管理的寫協議確保了只有最近一個版本被寫入磁碟中。它同時需要確保其他之前的版本從其他cache中被清洗。一個寫磁碟的請求可以從任意一個Instance上發起，無論它是儲存了block的當前版本還是過去的版本。假設第一個Instance hold過去的block映象，請求Oracle將buffer寫入磁碟，如上圖，過程如下：

①第一個Instance傳送一個寫請求給GCS

②GCS將請求轉給第二個Instance，當前該block的holder

③第二個Instance接到寫請求後將block寫入磁碟

④第二個Instance通知GCS，告知其寫操作完成

⑤當接到GCS接到通知後，GCS命令所有的過去的映象的holders刪除其過去的映象。此映象將不會在因恢復而需要。

12、RAC和Instance/crash recovery

1)當一個Instance失敗，當該失敗被其他Instance檢測到，第二個Instance將會執行下面的恢復操作：

①在恢復的第一階段，GES重新灌入佇列

②GCS也重新灌入其資源。GCS程序只重新灌入那些失去其控制的資源。在這期間，所有的GCS資源請求和寫請求都臨時被掛起。然而，事務可以繼續修改data blocks，只要這些事務已經獲得了必要的資源。

③當佇列被重新配置後，一個活動的Instance可以獲得佔有該Instance恢復佇列。因此，當GCS資源被重新灌入的同時，SMON確定需要被恢復的blocks的集合。這個集合被稱作恢復集。因為，使用cache 融合演算法，一個Instance傳送這些blocks的內容到請求的Instance，而不需要將這些blocks寫入磁碟。這些blocks在磁碟上的版本可能不包含其他Instance程序的data的修改操作的blocks。這意味著SMON需要合併所有失敗的Instance的redo logs來確定恢復集。這是因為一個失敗的執行緒可能導致一個在redo 中的hole(洞)需要用指定的block填補。所以失敗的Instance的redo 執行緒不能被連續的應用。同時，活動的Instances的redo 執行緒不需恢復，因為SMON可以使用過去和當前的通訊緩衝的映象。

④用於恢復的緩衝空間被分配，並且那些之前讀取redo logs被辨識的資源被宣告為恢復資源。這避免了其他Instance訪問這些資源。

⑤所有在隨後的恢復操作中需要的資源被獲得，並且GRD當前是不凍結的。任何不需恢復的data block現在可以被訪問。所以當前系統時部分可用的。此時，假設有過去或當前的blocks映象需要被恢復，而其在cluster Database中的其他caches中，對於這些特殊的blocks，最近的映象是開始恢復點。如果對於要恢復的block，過去映象和當前映象緩衝都不在活動的Instance的caches中，則SMON將寫入一個log，表明合併失敗。SMON會對第三步中辨識的每個block進行恢復和寫入，在恢復之後會馬上釋放資源，從而使更多的資源在恢復時可以被使用。

當所有的block被恢復，佔用的恢復資源被釋放，則系統再次可用。

note：在恢復中，log合併的開支和失敗的Instances的數目是成比例的，並且與每個Instance的redo logs的大小有關。

2)Instance recovery和Database availability

上圖顯示了在進行Instance恢復時，每一步執行時資料庫的可用程度：

A. RAC執行在多節點上

B. 有節點失敗被檢測到

C. GRD的佇列部分被重新設定;資源管理被重新分配到活動的nodes。此操作的執行比較快

D. GRD的緩衝部分被重新設定，SMON讀取失敗Instance的redo logs辨識那些需要恢復的blocks的集合

E. SMON向GRD發起請求，獲得所有在需要恢復的blocks集合中的Database blocks。當請求結束，所有的其他的blocks都可被訪問了

F. Oracle執行滾動的向前恢復。失敗執行緒的redo logs被應用到Database，並且那些被完全恢復的blocks將馬上可以被訪問

G. Oracle執行滾回恢復。對於尚未提交的事務，undo blocks被應用到Database中

H. Instance的恢復完成，所有的data可以被訪問

13、有效的內部節點行級鎖

Oracle支援有效的行級鎖。這些行級鎖主要是在DML操作時被建立，例如UPDATE。這些鎖被持有，直到事務被提交或回滾。任何請求同行的lock的程序都將被掛起。

cache融合演算法的塊傳輸獨立於這些user可見的行級鎖。GCS對blocks的傳輸是一個底層的操作，無需當代行級鎖被釋放就開始進行。blocks可能被從一個Instance傳輸到其他其他Instances，同時該blocks可能被加鎖。

GCS提供對data blocks的訪問，允許多個事務的併發進行。

14、RAC的額外的記憶體需求

RAC特有的記憶體多數是在SGA建立時從shared pool中分配的。因為blocks可能跨越Instances被緩衝，必須要求更大的緩衝區。因此，當將single Instance的Database遷移到RAC中時，保持每個Instance的請求工作量都能通single-instance時的情況，則需要對執行RAC的Instance增大10%的buffer cache和15%的shared pool。這些值只是基於RAC大小的經驗，一個初始的嘗試值。一般會大於此值。

如果正在使用推薦的自動記憶體管理特性，可以通過修改SGA_TARGET初始引數來設定。但考慮到同樣數量的user訪問被分散到多個nodes中，每個Instance的記憶體需求可以被降低。

實際資源的使用可以通過查詢每個Instance中的GCS和GES實體中的檢視V$RESOURCE_LIMIT檢視CURRENT_UTILIZATION和MAX_UTILIZATION欄位，具體語句為：

SELECT resource_name, current_utilization, max_utilization FROM v$resource_limit WHERE resource_name like ‘g%s_%’;

15、RAC與併發執行

Oracle的優化器是基於執行訪問代價的，這就考慮了併發執行的代價，並將其作為獲得理想的執行計劃的一個部件。

在RAC環境中，優化器的併發選擇是由內部節點和外部節點併發兩類組成的。例如，一個特殊的查詢請求需要六個查詢程序完成，並且在本地節點有六個併發的從屬執行程序都是idle的，則查詢通過使用本地資源執行，從而獲得結果。這闡述了有效地內部節點併發，也無需多節點併發的查詢協調的開支。如果本地節點中只有兩個併發執行從屬程序可用，則這兩個程序和其他節點的四個程序共同執行查詢。在這種情況下，內部節點和外部節點併發都被使用到，從而加速查詢。

在真實環境的決策支援應用程式中，查詢不能通過各種查詢servers得到較好的劃分。所以有些併發執行servers完成其任務後先於其他servers變為idle狀態。Oracle併發執行技術動態監測idle的程序，並將超載程序的隊列表中的任務分配任務給處於idle狀態的程序。這樣，Oracle有效的再分配了所有程序的查詢工作量。RAC進一步擴充套件這個效率到整個cluster上。

16、全域性動態效能檢視

全域性動態效能檢視顯示所有開啟並訪問RAC Database的Instances相關的資訊。而標準動態效能檢視只顯示了本地Instance的相關資訊。

對於所有V$型別的檢視，都會對應一個GV$檢視，除了幾個別的特殊情況。除了V$檢視中的columns，GV$檢視中包含了一個名為INST_ID的額外的column，顯示了RAC中的Instance number。可以在任何開啟的Instance上訪問GV$。

為了查詢GV$檢視，每個Instance上的初始PARALLEL_MAX_SERVERS初始化引數至少設定為1 。這是由於對GV$的查詢使用了特殊的併發執行。併發執行的協調者執行在客戶端連線的Instance上，並且每個Instance上分配一個slave用於查詢其潛在的V$檢視。如果有一個Instance上的PARALLEL_MAX_SERVERS被設定為0，則無法獲得該node的資訊，同理，如果所有的併發servers非常忙，則也無法獲得結果。在以上兩種情況下，不會獲得提示或錯誤資訊。

17、RAC和Service

18、虛擬IP地址和RAC

當一個node完全失敗，虛擬IP地址(VIP)是關於所有有效應用的。當一個節點失敗，其相關的VIP自動的分派到cluster中的其他node上。當這種情況出現時：

* crs在另外一個node的網絡卡的MAC地址上繫結這個ip,對使用者來說是透明的。對於直接連線的客戶端，會顯示errors。

* 隨後發往VIP的資料包都將轉向新的節點，它將給客戶端傳送error RST返回包。從而使客戶端快速的獲得errors資訊，進行對其他節點的連線重試。

如果不使用VIP，則一個node失敗後，發往該節點的連線將等待10分鐘的TCP過期時間。

轉自：http://blog.csdn.net/mws1108/article/details/52856762

--- 另一篇文章參考

叢集概念介紹

叢集術語須知

服務硬體：指提供計算服務的硬體，比如 PC 機、PC 伺服器。

服務實體：服務實體通常指服務軟體和服務硬體。

節點（node）：執行 Heartbeat 程序的一個獨立主機稱為節點，節點是 HA 的核心組成部分，每個節點上執行著作業系統和Heartbeat 軟體服務。

資源（resource）：資源是一個節點可以控制的實體，當節點發生故障時，這些資源能夠被其他節點接管。如： 磁碟分割槽、檔案系統、IP 地址、應用程式服務、共享儲存

事件（event）：事件也就是叢集中可能發生的事情，例如節點系統故障、網路連通故障、網絡卡故障和應用程式故障等。這些事件都會導致節點的資源發生轉移，HA 的測試也是基於這些事件進行的。

什麼是叢集

叢集（cluster）就是一組計算機，它們作為一個整體向用戶提供一組網路資源，這些單個的計算機系統就是叢集的節點（node）。叢集提供了以下關鍵的特性。

(一) 可擴充套件性。叢集的效能不限於單一的服務實體，新的服務實體可以動態的加入到叢集，從而增強叢集的效能。

(二) 高可用性。叢集通過服務實體冗餘使客戶端免於輕易遭遇到“out of service”警告。當一臺節點伺服器發生故障的時候，這臺伺服器上所執行的應用程式將在另一節點伺服器上被自動接管。消除單點故障對於增強資料可用性、可達性和可靠性是非常重要的。

(三) 負載均衡。負載均衡能把任務比較均勻的分佈到叢集環境下的計算和網路資源，以便提高資料吞吐量。

(四) 錯誤恢復。如果叢集中的某一臺伺服器由於故障或者維護需要而無法使用，資源和應用程式將轉移到可用的叢集節點上。這種由於某個節點中的資源不能工作，另一個可用節點中的資源能夠透明的接管並繼續完成任務的過程叫做錯誤恢復。

分散式與叢集的聯絡與區別如下：

(一) 分散式是指將不同的業務分佈在不同的地方。

(二) 而叢集指的是將幾臺伺服器集中在一起，實現同一業務。

(三) 分散式的每一個節點，都可以做叢集，而叢集並不一定就是分散式的。而分散式，從狹義上理解，也與叢集差不多，但是它的組織比較鬆散，不像叢集，有一定組織性，一臺伺服器宕了，其他的伺服器可以頂上來。分散式的每一個節點，都完成不同的業務，一個節點宕了，這個業務就不可訪問了。

叢集主要分成三大類：

HA：高可用叢集（High Availability Cluster）。

LBC：負載均衡叢集/負載均衡系統（Load Balance Cluster）

HPC：科學計算叢集（High Performance Computing Cluster）/高效能運算（High Performance Computing）叢集。

為什麼搭建資料庫叢集

隨著經濟的高速發展，企業規模的迅猛擴張，企業使用者的數量、資料量的爆炸式增長，對資料庫提出了嚴峻的考驗。對於所有的資料庫而言，除了記錄正確的處理結果之外，還面臨著以下幾方面的挑戰。

• l  如何提高處理速度，實現資料庫的均衡負載。
• l  如何保證資料庫的可用性、資料安全性、以及如何實現資料叢集可擴性。
• l  怎麼綜合解決這些問題成為眾多企業關注的焦點。

在資料庫上，組建叢集也是同樣的道理，主要有以下幾個原因：

(一) 伴隨著企業的成長，業務量提高，資料庫的訪問量和資料量快速增長，其處理能力和計算速度也相應增大，使得單一的裝置根本無法承擔。

(二) 在以上情況下，若扔掉現有裝置，做大量的硬體升級，勢必造成現有資源的浪費，而且下一次業務量提升時，又將面臨再一次硬體升級的高額投入。於是，人們希望通過幾箇中小型伺服器組建叢集，實現資料庫的負載均衡及持續擴充套件；在需要更高資料庫處理速度時，只要簡單的增加資料庫伺服器就可以得到擴充套件。

(三) 資料庫作為資訊系統的核心，起著非常重要的作用，單一裝置根本無法保證系統的下持續執行，若發生系統故障，將嚴重影響系統的正常執行，甚至帶來巨大的經濟損失。於是，人們希望通過組建資料庫叢集，實現資料庫的高可用，當某節點發生故障時，系統會自動檢測並轉移故障節點的應用，保證資料庫的持續工作。

(四) 企業的資料庫儲存著企業的重要資訊，一些核心資料甚至關係著企業的命脈，單一裝置根本無法保證資料庫的安全性，一旦發生丟失，很難再找回來。於是，人們希望通過組建資料庫叢集，實現資料集的冗餘，通過備份資料來保證安全性。

資料庫叢集的分類

資料庫叢集技術是將多臺伺服器聯合起來組成叢集來實現綜合性能優於單個大型伺服器的技術，這種技術不但能滿足應用的需要，而且大幅度的節約了投資成本。資料庫叢集技術分屬兩類體系：基於資料庫引擎的叢集技術和基於資料庫閘道器（中介軟體）的叢集技術。在資料庫叢集產品方面，其中主要包括基於資料庫引擎的叢集技術的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基於資料庫閘道器（中介軟體）的叢集技術的 ICX-UDS 等產品。

一般來講，資料庫叢集軟體側重的方向和試圖解決的問題劃分為三大類：

• l  負載均衡叢集（Load Balance Cluster，LBC）側重於資料庫的橫向擴充套件，提升資料庫的效能。
• l  高可用性叢集（High Availability Cluster，HAC）側重保證資料庫應用持續不斷。大部分的資料庫叢集側重與此。
• l  高安全性叢集（High Security Cluster，HSC）側重於容災。

只有 Oracle RAC 能實現以上三方面

可擴充套件的分散式資料庫架構

(一) Oracle RAC：

其架構的最大特點是共享儲存架構（Shared-storage），整個 RAC 叢集是建立在一個共享的儲存裝置之上的，節點之間採用高速網路互聯。OracleRAC 提供了非常好的高可用特性，比如負載均衡和應用透明切塊（TAF），其最大的優勢在於對應用完全透明，應用無需修改便可切換到RAC 叢集。但是RAC 的可擴充套件能力有限，首先因為整個叢集都依賴於底層的共享儲存，所以共享儲存的 I/O 能力和可用性決定了整個叢集的可以提供的能力，對於 I/O 密集型的應用，這樣的機制決定後續擴容只能是 Scale up（向上擴充套件）型別，對於硬體成本、開發人員的要求、維護成本都相對比較高。Oracle顯然也意識到了這個問題，在 Oracle 的 MAA（Maximum Availability Architecture）架構中，採用 ASM 來整合多個儲存裝置的能力，使得 RAC 底層的共享儲存裝置具備線性擴充套件的能力，整個叢集不再依賴於大型儲存的處理能力和可用性。

RAC 的另外一個問題是，隨著節點數的不斷增加，節點間通訊的成本也會隨之增加，當到某個限度時，增加節點可能不會再帶來效能上的提高，甚至可能造成效能下降。這個問題的主要原因是 Oracle RAC 對應用透明，應用可以連線叢集中的任意節點進行處理，當不同節點上的應用爭用資源時，RAC 節點間的通訊開銷會嚴重影響叢集的處理能力。所以對於使用 ORACLE RAC 有以下兩個建議：

• l  節點間通訊使用高速網際網路絡；
• l  儘可能將不同的應用分佈在不同的節點上。

基於這個原因，Oracle RAC 通常在 DSS 環境（決策支援系統Decision Support System ，簡稱DSS)中可以做到很好的擴充套件性，因為 DSS 環境很容易將不同的任務分佈在不同計算節點上，而對於 OLTP 應用（On-Line Transaction Processing聯機事務處理系統），Oracle RAC 更多情況下用來提高可用性，而不是為了提高擴充套件性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 完全不同，它採用 無共享架構Shared nothing（shared nothing architecture）。整個叢集由管理節點(ndb_mgmd)，處理節點(mysqld)和儲存節點(ndbd)組 成，不存在一個共享的儲存裝置。MySQL cluster 主要利用了 NDB 儲存引擎來實現，NDB 儲存引擎是一個記憶體式儲存引擎，要求資料必須全部載入到記憶體之中。資料被自動分佈在叢集中的不同存 儲節點上，每個儲存節點只儲存完整資料的一個分片(fragment)。同時，使用者可以設定同一份資料儲存在多個不同的儲存節點上，以保證單點故障不會造 成資料丟失。MySQL cluster 主要由 3 各部分組成：

• l  SQL 伺服器節點
• l  NDB 資料儲存節點
• l  監控和管理節點

這樣的分層也是與 MySQL 本身把 SQL 處理和儲存分開的架構相關係的。MySQL cluster 的優點在於其是一個分散式的資料庫叢集，處理節點和儲存節點都可以線性增加，整個叢集沒有單點故障，可用性和擴充套件性都可以做到很高，更適合 OLTP 應用。但是它的問題在於：

• l   NDB（“NDB” 是一種“記憶體中”的儲存引擎，它具有可用性高和資料一致性好的特點。） 儲存引擎必須要求資料全部載入到記憶體之中，限制比較大，但是目前 NDB 新版本對此做了改進，允許只在記憶體中加 載索引資料，資料可以儲存在磁碟上。
• l  目前的 MySQL cluster 的效能還不理想，因為資料是按照主鍵 hash 分佈到不同的儲存節點上，如果應用不是通過主鍵去獲取資料的話，必須在所有的儲存節點上掃描， 返回結果到處理節點上去處理。而且，寫操作需要同時寫多份資料到不同的儲存節點上，對節點間的網路要求很高。

雖然 MySQL cluster 目前效能還不理想，但是 share nothing 的架構一定是未來的趨勢，Oracle 接手 MySQL之後，也在大力發展 MySQL cluster，我對 MySQL cluster 的前景抱有很大的期待。

(三) 分散式資料庫架構

MySQL 5 之後才有了資料表分割槽功能（Sharding）， Sharding 不是一個某個特定資料庫軟體附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴充套件(Scale Out，亦或橫向擴充套件、向外擴充套件)的解決方案，其主要目的是為突破單節點資料庫伺服器的 I/O 能力限制，解決資料庫擴充套件性問題。比如 Oracle 的 RAC 是採用共享儲存機制，對於 I/O 密集型的應用，瓶頸很容易落在儲存上，這樣的機制決定後續擴容只能是 Scale Up（向上擴充套件） 型別，對於硬體成本、開發人員的要求、維護成本都相對比較高。Sharding 基本上是針對開源資料庫的擴充套件性解決方案，很少有聽說商業資料庫進行 Sharding 的。目前業界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。

Sharding 架構的優勢在於，叢集擴充套件能力很強，幾乎可以做到線性擴充套件，而且整個叢集的可用性也很高，部分節點故障，不會影響其他節點提供服務。Sharding 原理簡單，容易實現，是一種非常好的解決資料庫擴充套件性的方案。Sharding 並不是資料庫擴充套件方案的銀彈，也有其不適合的場景，比如處理事務型的應用它可能會造成應用架構複雜或者限制系統的功能，這也是它的缺陷所在。讀寫分離是架構分散式系統的一個重要思想。不少系統整體處理能力並不能同業務的增長保持同步，因此勢必會帶來瓶頸，單純的升級硬體並不能一勞永逸。針對業務型別特點，需要從架構模式進行一系列的調整，比如業務模組的分割，資料庫的拆分等等。集中式和分散式是兩個對立的模式，不同行業的應用特點也決定了架構的思路。如網際網路行業中一些門戶站點，出於技術和成本等方面考慮，更多的採用開源的資料庫產品(如 MYSQL)，由於大部分是典型的讀多寫少的請求，因此為 MYSQL 及其複製技術大行其道提供了條件。而相對一些傳統密集交易型的行業，比如電信業、金融業等，考慮到單點處理能力和可靠性、穩定性等問題，可能更多的採用商用資料庫，比如 DB2、Oracle 等。就資料庫層面來講，大部分傳統行業核心庫採用集中式的架構思路，採用高配的小型機做主機載體，因為資料庫本身和主機強大的處理能力，資料庫端一般能支撐業務的運轉，因此，Oracle 讀寫分離式的架構相對MYSQL 來講，相對會少。讀寫分離架構利用了資料庫的複製技術，將讀和 寫分佈在不同的處理節點上，從而達到提高可用性和擴充套件性的目的。最通常的做法是利用 MySQL Replication 技術，Master DB 承擔寫操作，將資料變化複製到多臺 Slave DB上，並承擔讀的操作。這種架構適合 read-intensive 型別的應用，通過增加 Slave DB 的數量，讀的效能可以線性增長。為了避免 Master DB 的單點故障，叢集一般都會採用兩臺 Master DB 做雙機熱備，所以整個叢集的讀和寫的可用性都非常高。除了 MySQL，Oracle 從 11g 開始提供 Active Standby 的功能，也具備了實現讀寫分離架構的基礎。讀寫分離架構的缺陷在於，不管是 Master 還是 Slave，每個節點都必須儲存完整的資料，如 果在資料量很大的情況下，叢集的擴充套件能力還是受限於單個節點的儲存能力，而且對於 Write-intensive 型別的應用，讀寫分離架構並不適合。

採用 Oracle 讀寫分離的思路，Writer DB 和 Reader DB 採用日誌複製軟體實現實時同步； Writer DB 負責交易相關的實時查詢和事務處理，Reader DB 負責只讀接入，處理一些非實時的交易明細,報表類的彙總查詢等。同時，為了滿足高可用性和擴充套件性等要求，對讀寫端適當做外延，比如 Writer DB 採用 HA 或者 RAC 的架構模式，目前，除了資料庫廠商的 叢集產品以外，解決資料庫擴充套件能力的方法主要有兩個：資料分片和讀寫分離。資料分片(Sharding)的原理就是將資料做水平切分，類似於 hash 分割槽 的原理，通過應用架構解決訪問路由和Reader DB 可以採用多套，通過負載均衡或者業務分離的方式，有效分擔讀庫的壓力。

對於 Shared-nothing 的資料庫架構模式，核心的一個問題就是讀寫庫的實時同步；另外，雖然 Reader DB只負責業務查詢，但並不代表資料庫在功能上是隻讀的。只讀是從應用角度出發，為了保證資料一致和衝突考慮，因為查詢業務模組可能需要涉及一些中間處理，如果需要在資料庫裡面處理(取決與應用需求和設計)，所以Reader DB 在功能上仍然需要可寫。下面談一下資料同步的技術選型問題：

能實現資料實時同步的技術很多，基於 OS 層(例如 VERITAS VVR)，基於儲存複製(中高階儲存大多都支援)，基於應用分發或者基於資料庫層的技術。因為資料同步可能並不是單一的 DB 整庫同步，會涉及到業務資料選擇以及多源整合等問題，因此 OS 複製和儲存複製多數情況並不適合做讀寫分離的技術首選。基於日誌的 Oracle 複製技術，Oracle 自身元件可以實現，同時也有成熟的商業軟體。選商業的獨立產品還是 Oracle 自身的元件功能，這取決於多方面的因素。比如團隊的相應技術運維能力、專案投入成本、業務系統的負載程度等。

採用 Oracle 自身元件功能，無外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，對比來說，Stream 最靈活，但最不穩定，11g Physical Standby 支援恢復與只讀並行，但由於並不是日誌的邏輯應用機制，在讀寫分離的場景中最為侷限。如果技術團隊對相關技術掌握足夠充分，而選型方案的處理能力又能支撐資料同步的要求，採用 Oracle 自身的元件完全可行。選擇商業化的產品，更多出於穩定性、處理能力等考慮。市面上成熟的 Oracle 複製軟體也無外乎幾種，無論是老牌的 Shareplex，還是本土 DSG 公司的 RealSync 和九橋公司的 DDS，或是 Oracle 新貴 Goldengate，都是可供選擇的目標。隨著 GoldenGate 被 Oracle 收購和推廣，個人認為 GoldenGate 在容災、資料分發和同步方面將大行其道。當然，架構好一個可靠的分散式讀寫分離的系統，還需要應用上做大量設計，不在本文討論範圍內。

(四)  CAP 和 BASE 理論

分散式領域 CAP 理論：

• l  Consistency(一致性), 資料一致更新，所有資料變動都是同步的
• l  Availability(可用性), 好的響應效能
• l  Partition tolerance(分割槽容錯性) 可靠性

定理：任何分散式系統只可同時滿足二點，沒法三者兼顧。

忠告：架構師不要將精力浪費在如何設計能滿足三者的完美分散式系統，而是應該進行取捨。

關係資料庫的 ACID 模型擁有 高一致性 + 可用性 很難進行分割槽：

• l  Atomicity 原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。
• l  Consistency 一致性. 在事務開始或結束時，資料庫應該在一致狀態。
• l  Isolation 隔離層. 事務將假定只有它自己在操作資料庫，彼此不知曉。
• l  Durability. 一旦事務完成，就不能返回。

(五)  跨資料庫事務

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，也就是說傳統關係型資料庫要想實現一個分散式資料庫叢集非常困難，關係型資料庫的擴充套件能力十分有限。而近年來不斷髮展壯大的 NoSQL（非關係型的資料庫）運動，就是通過犧牲強一致性，採用 BASE 模型，用最終一致性的思想來設計分散式系統，從而使得系統可以達到很高的可用性和擴充套件性。那麼，有沒有可能實現一套分散式資料庫叢集，既保證可用性和一致性，又可以提供很好的擴充套件能力呢？

BASE 思想的主要實現有按功能劃分資料庫 sharding 碎片BASE 思想主要強調基本的可用性，如果你需要 High 可用性，也就是純粹的高效能，那麼就要以一致性或容錯性為犧牲，BASE 思想的方案在效能上還是有潛力可挖的。

• l  共同點：都是關係資料庫 SQL 以外的可選方案，邏輯隨著資料分佈，任何模型都可以自己持久化，將資料處理和資料儲存分離，將讀和寫分離，儲存可以是非同步或同步，取決於對一致性的要求程度。
• l  不同點：NOSQL 之類的 Key-Value 儲存產品是和關係資料庫頭碰頭的產品 BOX，可以適合非 Java 如 PHP RUBY等領域，是一種可以拿來就用的產品，而領域模型 + 分散式快取 + 儲存是一種複雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。

目前，已經有很多分散式資料庫的產品，但是絕大部分是面向 DSS 型別的應用，因為相比較 OLTP 應用，DSS 應用更容易做到分散式擴充套件，比如基於 PostgreSQL 發展的 Greenplum，就很好的解決了可用性和擴充套件性的問題，並且提供了很強大的平行計算能力。對於 OLTP 應用，業務特點決定其要求：高可用性，一致性， 響應時間短，支援事務和 join 等等。資料庫和 NoSQL當越來越多的 NoSQL 產品湧現出來，它們具備很多關係型資料庫所不具備的特性，在可用性和擴充套件性方面都可以做到很好。

第一，NoSQL 的應用場景非常侷限，某個型別的 NoSQL 僅僅針對特定型別的應用場景而設計。而關係型資料庫則要通用的多，使用 NoSQL 必須搞清楚自己的應用場景是否適合。

第二，利用關係型資料庫配合應用架構， 比如 Sharding 和讀寫分離技術，同樣可以搭建出具備高可用和擴充套件性的分散式資料庫叢集。

第三，關係型資料庫廠商依然很強大，全世界有大量的 使用者，需求必然會推動新的產品問世。

第四，硬體的發展日新月異，比如快閃記憶體的技術的不斷成熟，未來快閃記憶體可以作為磁碟與記憶體之間的 cache，或者完 全替代磁碟。而記憶體價格越來越低，容量越來越大，In-memory cache 或 database 的應用越來越廣泛，可以給應用帶來數量級的效能提升。資料庫面臨的 IO 問題將被極大改善。

Oracle叢集概念和原理

Oracle的三種高可用叢集方案

1 RAC（Real Application Clusters）

                       

多個Oracle伺服器組成一個共享的Cache，而這些Oracle伺服器共享一個基於網路的儲存。這個系統可以容忍單機/或是多機失敗。不過系統內部的多個節點需要高速網路互連，基本上也就是要全部東西放在在一個機房內，或者說一個數據中心內。如果機房出故障，比如網路不通，那就壞了。所以僅僅用RAC還是滿足不了一般網際網路公司的重要業務的需要，重要業務需要多機房來容忍單個機房的事故。

2 Data Guard.（最主要的功能是冗災）

 

Data Guard這個方案就適合多機房的。某機房一個production的資料庫，另外其他機房部署standby的資料庫。Standby資料庫分物理的和邏輯的。物理的standby資料庫主要用於production失敗後做切換。而邏輯的standby資料庫則在平時可以分擔production資料庫的讀負載。

3 MAA

 

MAA(Maximum Availability Architecture)其實不是獨立的第三種，而是前面兩種的結合，來提供最高的可用性。每個機房內部署RAC叢集，多個機房間用Data Guard同步。

RAC概述

共享儲存檔案系統（NFS），或甚至叢集檔案系統（如：OCFS2）主要被用於儲存區域網路（所有節點直接訪問共享檔案系統上儲存器），這就使得節點失效而不影響來自其他節點對檔案系統的訪問，通常，共享磁碟檔案系統用於高可用叢集。

Oracle RAC的核心是共享磁碟子系統，叢集中所有節點必須能夠訪問所有資料、重做日誌檔案、控制檔案和引數檔案，資料磁碟必須是全域性可用的，允許所有節點訪問資料庫，每個節點有它自己的重做日誌和控制檔案，但是其他節點必須能夠訪問它們以便在那個節點出現系統故障時能夠恢復。

Oracle RAC 運行於叢集之上，為 Oracle 資料庫提供了最高級別的可用性、可伸縮性和低成本計算能力。如果叢集內的一個節點發生故障，Oracle 將可以繼續在其餘的節點上執行。Oracle 的主要創新是一項稱為快取記憶體合併的技術。快取記憶體合併使得叢集中的節點可以通過高速叢集互聯高效地同步其記憶體快取記憶體，從而最大限度地低降低磁碟 I/O。快取記憶體最重要的優勢在於它能夠使叢集中所有節點的磁碟共享對所有資料的訪問。資料無需在節點間進行分割槽。Oracle 是唯一提供具備這一能力的開放系統資料庫的廠商。其它聲稱可以執行在叢集上的資料庫軟體需要對資料庫資料進行分割槽，顯得不切實際。企業網格是未來的資料中心，構建於由標準化商用元件構成的大型配置之上，其中包括：處理器、網路和儲存器。Oracle RAC 的快取記憶體合併技術提供了最高等級的可用性和可伸縮性。Oracle 資料庫 10g 和 OracleRAC 10g 顯著降低了運營成本，增強了靈活性，從而賦予了系統更卓越的適應性、前瞻性和靈活性。動態提供節點、儲存器、CPU 和記憶體可以在實現所需服務級別的同時，通過提高的利用率不斷降低成本。

RAC 整合叢集件管理

Oracle RAC 10g 在 Oracle 資料庫 10g 執行的所有平臺上提供了一個完整整合的叢集件管理解決方案。這一叢集件功能包括叢集連線、訊息處理服務和鎖定、叢集控制和恢復，以及一個工作負載管理框架（將在下文探討）。Oracle RAC 10g 的整合叢集件管理具有以下優勢：

(一) 成本低。Oracle 免費提供這一功能。

(二) 單一廠商支援。消除了相互推諉的問題。

(三) 安裝、配置和持續維護更簡單。Oracle RAC 10g 叢集件使用標準 Oracle 資料庫管理工具進行安裝、配置和維護。這一過程無須其它的整合步驟。

(四) 所有平臺，質量始終如一。與第三方產品相比，Oracle 對新軟體版本進行了更嚴格的測試。

(五) 所有平臺，功能始終如一。例如，一些第三方叢集件產品限制了叢集內可以支援的節點的數量。藉助Oracle RAC 10g，所有平臺可以支援多達 64 個節點。使用者還可以在所有平臺上獲得一致的響應體驗，從而有效解決了高可用性挑戰，包括伺服器節點故障、互連故障以及 I/O 隔離現象等。

(六) 支援高階功能。這包括整合監視和通知功能，從而在發生故障時，在資料庫和應用層之間實現快速協調的恢復。

RAC 的體系結構

RAC 是 Oracle 資料庫的一個群集解決方案，是有著兩個或者兩個以上的資料庫節點協調運作能力的。如下圖所示的 RAC 結構圖：

 

叢集管理器（Cluster Manager）在集群系統中對其他各個模組進行整合，通過高速的內連線來提供群集節點之間的通訊。各節點之間內連線使用心跳線互聯，心跳線上的資訊功能確定群集邏輯上的節點成員資訊和節點更新情況，以及節點在某個時間點的執行狀態，保證群集系統正常執行。通訊層管理節點之間的通訊。它的職責是配置，互聯群集中節點資訊，在群集管理器中使用由心跳機制產生的資訊，由通訊層負責傳輸，確保資訊的正確到達。還有一些群集監視程序不斷驗證系統的不同領域執行狀況。例如，心跳監測不斷驗證的心跳機制的運作是否良好。在一個應用環境當中，所有的伺服器使用和管理同一個資料庫，目的是分散每一臺伺服器的工作量。硬體上至少需要兩臺以上的伺服器，而且還需要一個共享儲存裝置；同時還需要兩類軟體，一類是叢集軟體，另外一類就是 Oracle 資料庫中的 RAC 元件。同時所有伺服器上的 OS 都應該是同一類 OS，根據負載均衡的配置策略，當一個客戶端傳送請求到某一臺服務的 listener 後，這臺伺服器根據負載均衡策略，會把請求傳送給本機的 RAC元件處理，也可能會發送給另外一臺伺服器的 RAC 元件處理，處理完請求後，RAC 會通過群集軟體來訪問共享儲存裝置。邏輯結構上看，每一個參加群集的節點有一個獨立的例項，這些例項訪問同一個資料庫。節點之間通過叢集軟體的通訊層（Communication Layer）來進行通訊。同時為了減少 I/O 的消耗，存在一個全域性快取服務，因此每一個數據庫的例項，都保留了一份相同的資料庫 cache。RAC 中的特點如下：

• l   每一個節點的例項都有自己的 SGA；
• l   每一個節點的例項都有自己的後臺程序
• l   每一個節點的實力都有自己的 redo logs
• l   每一個節點的例項都有自己的 undo 表空間
• l   所有節點都共享一份 datafiles 和 controlfiles

RAC 的結構組成和機制

在 Oracle9i 之前，RAC 稱為 OPS（Oracle Parallel Server）。RAC 與 OPS 之間的一個較大區別是，RAC 採用了Cache Fusion（高快取合併）技術，節點已經取出的資料塊更新後沒有寫入磁碟前，可以被另外一個節點更新，然後以最後的版本寫入磁碟。在 OPS 中，節點間的資料請求需要先將資料寫入磁碟，然後發出請求的節點才可以讀取該資料。使用 Cache Fusion 時，RAC 的各個節點間資料緩衝區通過高速、低延遲的內部網路進行資料塊的傳輸。下圖是一個典型的 RAC 對外服務的示意圖，一個 Oracle RAC Cluster 包含了如下的部分

 

1. 叢集的節點（Cluster node）——2 個到 N 個節點或者主機執行 Oracle Database Server。
2. 私有網路（Network Interconnect）——RAC 之間需要一個高速互聯的私有網路來處理通訊和 Cache Fusion。
3. 共享儲存（shared Storage）——RAC 需要共享儲存裝置讓所有的節點都可以訪問資料檔案。
4. 對外服務的網路（Production Network）——RAC 對外服務的網路。客戶端和應用都通過這個網路來訪問。

RAC 後臺程序

Oracle RAC 有一些自己獨特的後臺程序，在單一例項中不發揮配置作用。如下圖所示，定義了一些 RAC 執行的後臺程序。這些後臺程序的功能描述如下。

 

（1）LMS（Global cache service processes 全域性快取服務程序）程序主要用來管理叢集內資料塊的訪問，並在不同例項的 Buffer Cache 中傳輸資料塊映象。直接從控制的例項的快取複製資料塊，然後傳送一個副本到請求的例項上。並保證在所有例項的 Buffer Cache 中一個數據塊的映象只能出現一次。LMS 程序靠著在例項中傳遞訊息來協調資料塊的訪問，當一個例項請求資料塊時，該例項的 LMD 程序發出一個數據塊資源的請求，該請求指向主資料塊的例項的 LMD 程序，主例項的 LMD 程序和正在使用的例項的 LMD 程序釋放該資源，這時擁有該資源的例項的 LMS 程序會建立一個數據塊映象的一致性讀然後把該資料塊傳遞到請求該資源的例項的BUFFER CACHE 中。LMS 程序保證了在每一時刻只能允許一個例項去更新資料塊，並負責保持該資料塊的映象記錄（包含更新資料塊的狀態 FLAG)。RAC 提供了 10 個 LMS 程序（0~9），該程序數量隨著節點間的訊息傳遞的資料的增加而增加。（2）LMON（Lock Monitor Process，鎖監控程序）是全域性佇列服務監控器，各個例項的 LMON 程序會定期通訊，以檢查叢集中各個節點的健康狀況，當某個節點出現故障時，負責叢集重構、GRD 恢復等操作，它提供的服務叫做 Cluster Group Service（CGS）。

LMON 主要藉助兩種心跳機制來完成健康檢查。

(一) 節點間的網路心跳（Network Heartbeat）：可以想象成節點間定時的傳送 ping 包檢測節點狀態，如果能在規定時間內收到迴應，就認為對方狀態正常。

(二) 通過控制檔案的磁碟心跳（controlfile heartbeat）：每個節點的 CKPT 程序每隔 3 秒鐘更新一次控制檔案的資料塊，這個資料塊叫做 Checkpoint Progress Record，控制檔案是共享的，所以例項間可以互相檢查對方是否及時更新來判斷。

(三) LMD（the global enqueue service daemon，鎖管理守護程序）是一個後臺程序，也被稱為全域性的佇列服務守護程序，因為負責對資源的管理要求來控制訪問塊和全域性佇列。在每一個例項的內部，LMD 程序管理輸入的遠端資