ORACLE DATABASE 11G RAC 知識圖文詳細教程之叢集概念介紹（一）

叢集概念介紹 叢集術語須知

服務硬體：指提供計算服務的硬體，比如 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 問題將被極大改善。