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

本文轉載自查看原文 2015-07-16 12:31 22106 Database Cluster

集群概念介紹（一）)

2015年7月16日

概述：寫下本文檔的初衷和動力，來源於上篇的《oracle基本操作手冊》。oracle基本操作手冊是作者研一假期對oracle基礎知識學習的匯總。然后形成體系的總結，一則進行回顧復習，另則便於查詢使用。本圖文文檔亦源於此。閱讀Oracle RAC安裝與使用教程前，筆者先對這篇文章整體構思和形成進行梳理。由於閱讀者知識儲備層次不同，我將從Oracle RAC安裝前的准備與規划開始進行整體介紹安裝部署Oracle RAC。始於唐博士指導，對數據庫集群進行配置安裝，前后經歷2，3個月的摸索。中間遇到不少問題。此文檔也將一一記錄整理。( 本文原創/整理，轉載請標注原文出處: 集群概念介紹（一）)

本文極客學院入口：Oracle-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 問題將被極大改善。