RAC是什么？
和單機概念進行對比：單機是一個實例，1個數據庫；RAC是多個實例，一個數據庫，多個實例之間共享一個數據庫，但是不是分布式，這就是RAC，簡單來說就是一個集群。
為什么會有RAC的需求？
為了實現數據的高可用，以數據的高可用為目標，這也是RAC最大的特點：
就像每家每戶用電一樣，作為用電戶總是不希望家里出現停電的情況，因為停電將對日常生活帶來極大的不便。同樣，作為信息系統的客戶也不希望系統出現異常情況，這同樣會影響客戶正常的生產和生活。
1）從硬件來說，為了追求信息系統更加高效穩定的運行，支撐信息系統運行的各個硬件組成部分，在產品長時間高效穩定運行方面得到了巨大的發展。
例如，UPS電源保證機房在斷電的情況下能支撐較長時間的供電，服務器有非常多不同於一般PC的設計來保證服務器能夠長時間穩定的運行，存儲系統也在不斷地發展與進步，這些是硬件方面的內容，是信息系統運行的基礎。
2）從軟件上來說，作為信息系統核心的數據庫產品在不斷增強產品質量的同時，也提出了自己的高可用性解決方案，並且這些方案也在不斷地增強和普及。而RAC數據庫就是Oracle公司針對數據庫的高可用性解決方案。
數據庫的高可用性依賴於硬件的穩定運行和設備的冗余，軟硬件高效穩定的協同工作才能夠保證系統更加安全、穩定和高效地運行。
RAC有什么優勢？
1）高可用性:RAC是Oracle數據庫產品高可用性的解決方案，能夠保證在集群中只要有一個節點存活，就能正常對外提供服務。
單節點數據庫，如果實例宕機了，如果一個業務鏈接在實例上面，那么這個業務就中斷了。這個時候系統就不具有可用性了，那么這個時候單節點的可用性是很差的。
2）雙機並行:RAC是一種並行模式，並不是傳統的主備模式。也就是說，RAC集群的所有成員都可以同時接收客戶端的請求。
RAC是一種充分利用服務器資源的高可用性實現方案，RAC的並行模式實現方式與傳統的雙機熱備實現方式截然不同，圖是兩者的比較。
如圖所示，兩個節點在傳統的雙機熱備環境中，始終有一台機器作為備用機，只有當主節點出現問題的時候才會切換到備用機上;如果主機一直沒有出現問題，那么備用機始終處於空閑狀態，這在資源的利用上以及成本方面都是巨大的浪費。但RAC是一種並行模式的架構，也就是說，兩個節點的集群節點間是一種並行運行的關系，當一台機器出現問題，請求會自動轉發到另一台機器，沒有任何一台機器作為備用機一直不被使用，這樣就充分利用了服務器資源。同時，傳統的雙機熱備構架在出現問題時，常常需要數分鍾的切換時間，而RAC在出現問題時，針對存在的會話只需要數十秒的時間就可以完成失敗切換過程，對新會話的創建不會產生影響，在切換時間上也有比較大的優勢。
3）易伸縮性：RAC可以非常容易地添加、刪除節點，以滿足系統自身的調整。
RAC為需要重新規划的應用提供了易擴展性。為了在系統初始階段保持較低的成本，避免造成不必要的浪費，集群可以按照標准硬件配置，選擇適當的服務器資源、存儲資源來搭建數據庫環境。當系統需要更多的處理能力或者需要增加存儲時，通過添加另一台服務器或存儲設備到集群中，能夠在不停機的情況下獲得水平的擴展。在一個集群中， Clusterware和RAC支持多達100個集群節點。
當某個集群的處理能力過剩，另一個集群的處理能力不夠時，可以從處理能力過剩的集群移動一個節點到處理能力不夠的集群中。這樣能夠充分利用服務器資源，節約成本。11gR2版本中推出了網格即插即用(Grid Plug and Play，GPnP)，可以實現節點的快速添加。
4）低成本：能使用較低廉的服務器來實現高可用性、高吞吐量的集群環境，這要比通過對某台高端服務器增加硬件實現高可用性、高吞吐量花費的成本低很多。
通過多台普通的PC服務器組成一個集群，可以提高集群的處理能力，這樣要比采用一台高性能的服務器的成本低很多。如果想提高系統的處理能力，給集群添加節點比為高性能服務器添加硬件要容易得多。另外，使用集群還能動態地移除節點，更加充分地利用管理者掌握的所有服務器資源，從服務器整體使用上降低了服務器的采購成本。越來越多的企業願意將集群解決方案應用到他們的系統中，以降低成本，提高系統的可用性。
5）高吞吐量：隨着節點數的增加，整個RAC的吞吐量也在不斷增長。
RAC是由多台服務器構成的邏輯主體，比單台數據庫服務器能接收更多的客戶端請求。這在要求高吞吐量的系統中，能夠得到非常明顯的體現。在RAC的架構中，多個實例分布在多個服務器上，能同時打開同一個數據庫，而每個實例能夠接收相等數量的客戶端請求，這樣，隨着服務器的增加，吞吐量也在不斷地增加。
RAC有什么劣勢？
1）RAC不能夠解決在數據安全方面的問題
盡管有多個實例，但是只有一份數據文件，這樣只要數據文件損壞了，那么整個數據庫就損壞了。
2）RAC的穩定性很難保證
數據庫的穩定運行是系統穩定運行的基礎和前提，數據庫的運行依賴於操作系統、服務器、存儲設備等軟硬件設備的運行情況。
由於各種硬件設備、操作系統的廠商不同，有時候在兼容性上會存在問題，即使同一個廠商的服務器，由於驅動、固件版本的不同也可能導致硬件出現問題以及與其他設備的兼容性問題。同時，由於RAC本身也存在不少bug，很多部署的RAC環境缺乏在上線前對環境的檢查和測試，導致在運行過程中出現一系列不穩定的情況，這樣高可用性並沒有得到充分的體現。
由此來看，穩定的硬件環境加上穩定的RAC版本，決定着RAC運行的穩定性。數據庫工程師與硬件工程師在安裝配置前大量的環境檢查、驗證，以及部署后的大量測試工作都是非常重要的。
3）RAC的高性能也很難保證
高性能也是大部分從單機環境遷移到RAC環境比較頭疼的問題，RAC並不是高性能的解決方案。在目前普遍使用千兆網絡的硬件環境中，很多時候系統的數據庫從原來的單機遷移至RAC環境，系統的性能反而下降。在這種情況下，數據庫管理員應該根據RAC的特點對系統調整提出合理的建議，經過合理的設計、開發，使用RAC是能夠提高系統的處理性能的。
RAC適用於什么場景？
1）對高可用要求比較高的場景
RAC和一般的“1個實例，1個數據庫”有什么區別？
1）實現更加復雜
2）需要了解的技術更多，搭建環境難度更大，可能遇到的問題更多，尤其是穩定性和高性能方面
3）高可用
要想了解透徹RAC，除了上面所述的基本知識，還需要了解什么？
RAC架構
在RAC里面，最重要的就是實例和實例之間的交互，即使是分離的實例，但是讀取的數據是相同的，RAC不是分布式的系統，因為它只有一個存儲，分布式系統是指數據發布在不同的數據庫上面，然后通過中間件來協調做查詢。RAC還是一台數據庫，多個實例。
對於RAC來說至少有兩套物理上不同的網絡，私有網絡是專門用來實例之間的數據交互。如果私有網絡，所有的數據都在一個網絡下面，那么那么就會對數據造成影響，嚴重的影響RAC的性能了。實例之間數據之間傳遞使用私有網絡和對外服務提供的網絡之間是物理分開的。所以RAC至少有兩套網絡，一個是實例之間的數據的傳遞，另外一個是公有網絡，是對外提供服務的，外面的業務是提供公有網絡的IP鏈接到數據庫的。
RAC的特點
除了具有普通的數據庫特性外：
每一個節點的instance都有自己的SGA
每一個節點的instance都有自己的background process
每一個節點的instance都有自己的redo logs
每一個節點的instance都有自己的undo表空間
每一個節點的實例都有自己的SGA，但是之間在SGA里面的數據塊都是需要相互傳遞的。
每一個節點都有自己的redo,redo不是共用的。雖然redo是放在共享磁盤上面，但是每個實例都有自己的redo，各有各的。當實例2壞了，實例1做恢復的時候可以通過實例2的redo信息來進行恢復。
每個實例都要處理自己的一套事務，所以需要使用自己的UNDO。
所以在RAC架構下面，每一套實例都有自己的東西。
RAC相關的后台進程？
一、RAC后台進程
LMON:LOCK Monitor Processes 也被稱為Global enqueue service monitor
監控整個集群狀況，維護GCS的內存結構 監控非正常終止的進程和實例 當實例離開和加入集群時，鎖和資源的重新配置 管理全局的鎖和資源 監控全局的鎖資源、處理死鎖和阻塞
LCK:Lock Process
LCK進程主要用來管理實例間資源請求和跨實例調用操作，調用操作包括數據字典等對像訪問，並處理非
CACEH FUSION的CHACE資源請求，（例如dictionary cache或row cache的請求） 由於LMS進程負責主要的鎖管理功能，所以每個實例只有一個LCK進程
LMD:Lock Monitor Deamon Process
LMD進程主要管理對全局隊列和資源的訪問，並更新相應隊列狀態，處理來自於其它實例的資源請，每一個全局隊列的當前狀態存儲在相應的實例共享內存中，該狀態表明該實例具有相應的權利使用該資源，一個實例master的共享內存中存在一個特殊的隊列，該隊列記錄來自其它遠程實例的資源請求，當遠程實例的LMD進程發出一個資源請求時，該請求指向master實例的LMD，當master實例的LMD進程受到該請求后，在共享內存中的特殊隊列中監測該資源是否有無效，如果有效LMD進程更新該資源對列的狀態，並通知請求資源的LMD進程該資源隊列可以使用了，如果資源隊列正被其它實例使用或當前無效，則LMD進程通知正在使用中的實例的LMD進程應用釋放該資源，等資源釋放變得有效時，master實例的LMD進程更新該資源隊列的狀態，並通知請求資源實例的LMD進程，該資源隊列可以使用了
全局隊列服務(GES)：主要負責維護字典緩存和庫緩存內的一致性。字典緩存是實例的 SGA 內所存儲的對數據字典信息的緩存，用於高速訪問。由於該字典信息存儲在內存中，因而在某個節點上對字典進行的修改（如DDL)必須立即被傳播至所有節點上的字典緩存。GES 負責處理上述情況，並消除實例間出現的差異。出於同樣的原因，為了分析影響這些對象的 SQL 語句，數據庫內對象上的庫緩存鎖會被去掉。這些鎖必須在實例間進行維護，而全局隊列服務必須確保請求訪問相同對象的多個實例間不會出現死鎖。LMON、LCK 和 LMD 進程聯合工作來實現全局隊列服務的功能。GES 是除了數據塊本身的維護和管理（由 GCS 完成）之外，在 RAC 環境中調節節點間其他資源的重要服務。
LMSn:Lock Monitor Services也稱作GCS（Global Cache Services）processes
LMS進程主要用來管理集群內數據庫的訪問，並在不同實例的buffer cache中傳輸塊鏡像，當在某個數據塊上
發生一致性讀時，LMS負責回滾該數據塊，並將它copy到請求的實例上 每個RAC節點至少有2個LMS進程
全局緩存服務(GCS):要和 Cache Fusion 結合在一起來理解，全局緩存要涉及到數據塊。全局緩存服務負責維護該全局緩沖存儲區內的緩存一致性，確保一個實例在任何時刻想修改一個數據塊時，都可獲得一個全局鎖資源，從而避免另一個實例同時修改該塊的可能性。進行修改的實例將擁有塊的當前版本（包括已提交的和未提交的事物）以及塊的前象(post image)。如果另一個實例也請求該塊，那么全局緩存服務要負責跟蹤擁有該塊的實例、擁有塊的版本是什么，以及塊處於何種模式。LMS 進程是全局緩存服務的關鍵組成部分。
DIAG:Diagnostic Deamon
oracle10g新的后台進程 例行對實例的健康情況進行監控，同時也監控實例是否掛起或者出現死鎖 收集實例和進程出錯時的關鍵診斷信息 這個進程會更新alert日志文件，寫入一些重要告警信息
二、RAC服務進程
CRS-集群資源服務(cluster ready services)
管理集群內高可用操作的基本程序 CRS管理的任何事務被稱之為資源 數據庫、實例、監聽、虛擬IP、應用進程等等 CRS是跟據存儲於OCR中的資源配置信息來管理這些資源 當一資源的狀態改變時，CRS進程生成一個事件，操作包括啟動、關閉、監控及故障切換，該進程由 root 用戶管理和啟動，CRSD如果有故障會導致系統重啟
CSS-集群同步服務(Cluster Synchronization Service)
管理集群節點的成員資格 控制哪 個結點為集群的成員、節點在加入或離開集群時通知集群成員來控制集群配置信息，此進程發生故障導致集群重啟,提供心跳機制監控集群狀態（DISK HEARTBEAT 和 NETWORK HEARBEAT），該進程由 oracle 用戶運行管理
EVMD事件管理服務(Event Management)
事件管理守護進程 發布CRS創建事件的后台進程
ONS-事件的發布及訂閱服務(Oracle Notification Service)
通信的快速應用通知事件的發布及訂閱服務
OCR- Oracle Cluster Register
集群注冊文件，記錄每個節點的相關信息 保存RAC集群的各種資源信息 類似於windows注冊表 存儲於共享磁盤上，所有實例共享 默認有2個互備磁盤
Voting Disk 表決磁盤
仲裁機制用於仲裁多個節點向共享節點財時寫的行為，避免發生沖突 存儲於共享磁盤上，所有實例共享 用於確定各個實例的關系 當有節點失效時，通過voting disk來決定驅逐哪個實例 默認有3個互備磁盤
OPROCD（Process Monitor Daemon）檢測 CPU hang（非 Linux 平台使用），集群進程管理 —Process monitor for the cluster. 用於保護共享數據 IO fencing
其他不理解的問題
Oracle 12c中的Flex概念
概述
12c的兩個新特性“Flex ASM”和“Flex 集群”兩個屬性，支持面向雲計算的環境的各種苛刻需求。
Oracle 12c引入的兩個新概念
中心節點（HUB NODE）： 和以前的版本一樣，它們通過專用網絡相互連接，並且可以直接訪問共享存儲。這些節點可以直接訪問 Oracle 集群注冊表 (OCR) 和表決磁盤 (VD)。這種結點上主要用來跑數據庫實例，也就是數據庫服務。每個hub node之間通過私網連接，而且需要配置ssh對等性。hub node上既運行ASM實例又運行db實例。每個flex cluster至少一個hub node最多64個hub node。
葉節點(LEAF NODE)： 這些節點是輕型節點，彼此不互連，也不能像中心節點一樣訪問共享存儲。每個葉節點與所連接的中心節點通信，並通過所連接的中心節點連接到集群。這種結點上主要用來跑應用，比如說什么系統之類的。不需要與集群中的其它數據庫服務器進行通信，只需要和它所連接的中心節點進行通信即可。雖然leaf node不要求直接訪問共享存儲，但最好還是連上共享存儲，因為說不准未來哪天就要把這個leaf node轉為hub node使用。leaf node上面不能運行ASM實例，也不能在上面建庫，因為上面運行的實例打開方式只能是只讀的。leaf node上可運行多種應用，例如中間件、EBS、IDM等，leaf node上的應用會在leaf node掛掉后自動切換到其他leaf node。
綜述：即使flex cluster中沒有一個leaf node， hub node也可以正常的像傳統rac節點一樣工作。但如果flex cluster中只有leaf node沒有一個hub node是萬萬不可的，因為leaf node需要通過hub node上的asm實例獲取數據。
當集群件啟動在leaf node上時，leaf node就會根據GNS信息查找所有hub node，然后選擇其中一個hub node來獲取數據(配置GNS是使用leaf node的重要前提)。一個hub node同時可能被0個或多個leaf node連接，而一個leaf node同時只能連接一個hub node。hub node和leaf node之間也會交換心跳信息，只有這樣leaf node才能加入集群並作為集群的一部分。
在 Oracle 12c 之前，對於要使用 ASM 的數據庫實例來說，所有節點上的 ASM 實例必須已處於運行狀態，才能啟動數據庫實例。如果 ASM 實例未運行，則意味着在存儲級使用 ASM 的數據庫實例不能啟動。這實際上意味着無論采用何種技術（即 RAC、ASM 和共享存儲），均不能訪問數據庫實例。
隨着 Oracle 12c 的推出，一個名為 Oracle Flex ASM 的特性解除了上述限制，它的一個主要特性是故障切換到集群中的其他節點。本質上是一個中心和葉架構，Oracle Clusterware 通過一個替代 ASM 實例將故障節點的連接將無縫轉移到另一個成員節點。(如果 Oracle 12c 數據庫實例與一個 ASM 實例的連接斷開，數據庫連接將故障切換至其他服務器上的另一個 ASM 實例)在給定集群中運行的 ASM 實例數被稱作 ASM 基數，默認值為 3。但此基數值可以使用 Clusterware 命令修改。
一個典型的 Oracle Flex 集群：
標准 Oracle Flex ASM 配置：
Oracle Flex ASM 配置上的 ASM 實例故障：
故障轉移如何理解？
當作為集群的一部分的某hub node掛了，將發生什么？
當發生如下情況時，hub node會被從集群中移除：
被驅逐
服務器關機
手動停止Oracle集群件
這種情況發生時，連接着這個hub node的leaf node會自動挑一個活着的hub node來作為數據源。也就是說，如果hub node掛了，那么通過這個hub node訪問集群的leaf node會自動切換至某存活的hub node繼續訪問集群。
Oracle RAC和Oracle cluster之間的關聯是什么？他們之間有什么區別？集群和分布式之間的關聯又是什么？節點的概念又是什么？
常見集群術語
服務硬件：指提供計算服務的硬件，比如 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和集群之間的關系）
(一) 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 RAC中的“雙活”概念
簡單來說，顧名思義，就是不止一個活着，而是至少有2個活着，對於數據庫而言，就是兩個節點都可以讀寫。
詳情需要后續繼續學習。
Oracle RAC中“心跳”的概念
RAC心跳分為3類，分別是網絡心跳、磁盤心跳和本地心跳：
（1）網絡心跳：所有節點每秒向其他所有節點發送信息確認對方是否“存活”。例如，在11.2版本以后，若某節點1超過30S未接受到某節點2的網絡心跳應答，則節點1認為節點2“死亡”，節點1會發起對節點2的驅逐。
（2）磁盤心跳：所有節點每秒與所有的VD通信，讀取VD的kill block信息判斷自己是否需要重啟，寫入自己通過網絡心跳了解到的集群信息到VD的OCR信息中。RAC 不允許任何節點與超過一半數目的VD失去訪問：
1）若節點的網絡心跳正常，RAC允許的VD超時時間為200S（LDTO）。若超過200S以后，節點不能訪問的VD數目超過了總VD數目的一半，則節點需要被驅逐和重啟。
2）若節點的網絡心跳失敗，RAC要求在27S（SDTO）內完成集群的重配置。
3）RAC對於VD也有相應的配置策略，要求配置N/2+1個VD，建議配置成奇數個。若某個VD長期不能被訪問，RAC會將其踢出，使用冗余的VD。
（4）本地心跳：所有節點需要對自己進行監控，若判斷自己無法正常工作將進行自我重啟，並在重啟前通知主控節點，將此集群變更信息廣播出去。重啟后，若節點判斷自己能正常工作，則再向主控節點發送加入集群的請求。（集群任何時候都有一個節點擔任主控節點）
————————————————
版權聲明：本文為CSDN博主「海狸_hlz」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_33410995/article/details/109521227