資料庫集群，顧名思義，就是利用至少兩台或者多台資料庫伺服器，構成一個虛擬單一資料庫邏輯映像，像單資料庫系統那樣，向客戶端提供透明的數據服務。
基本介紹
- 中文名：資料庫集群
- 利用：至少兩台或者多台資料庫伺服器
- 構成：一個虛擬單一資料庫邏輯映像
- 分類：以Oracle RAC為代表的系統等
定義,性質,套用,
定義
一.資料庫集群的定義
這裡有兩個關鍵點：
1. 兩台或者多台資料庫伺服器：如果只有一台資料庫伺服器是不能稱其為集群的。
2. 透明的服務：集群向客戶端提供的服務與單機系統向客戶端提供的服務，從通訊協定上保持二進制兼容。
二.相關名詞解釋
1.同步
資料庫客戶端發出數據更新請求後，要等集群的每個節點全部更新後，才給客戶端返回結果。
2.異步
資料庫客戶端發出數據更新請求後，接受請求的節點(這裡往往是主資料庫)立馬給客戶端返回結果，被更新的數據則會在接下來的某個時間裡被複製傳輸到集群的其它節點上(弱一致性處理)。
3.基於連線的負載均衡
此種負載均衡實現技術比較簡單，就是在客戶端發起登入的時候，按照某種負載均衡算法，選擇登入到集群某台資料庫，此後所有客戶端的請求全部會傳送到此資料庫上。
4.基於請求的負載均衡
此種負載均衡實現技術比較複雜，但是功能強大，就是在客戶端發起登入的時候，集群網關會同時登錄到集群各節點資料庫，此後所有的客戶端請求，經過集群網關的分析被分成兩類，查詢請求根據負載均衡算法挑選一個節點執行，數據更新請求則有主機執行並實時同步數據到集群各節點。
性質
一.與分散式資料庫系統的區別
- 資料庫集群有的具有單份數據集，有的具有兩份或多份相似的數據集，有的具有兩份或多份實時一致的數據集；而分散式資料庫系統往往具有完全不同的數據集。
- 資料庫集群往往是同構的系統，要求集群各節點都具有相同的作業系統和資料庫系統版本，甚至補丁包的版本也要求保持一致；而分散式資料庫系統可以是異構系統，包含不同的作業系統和不同的資料庫系統。
- 資料庫集群往往建立在高速區域網路內；而分散式資料庫系統既可以是高速區域網路，也可以是跨部門、跨單位的異地遠程網路。
二.資料庫集群的技術指標
由於資料庫系統是任何一個信息系統的核心，因此除了業務邏輯之外，用戶還關心下面三點：
1. 系統性能
性能問題涉及硬體、軟體、網路、套用設計架構、代碼質量等多方面。但是資料庫集群如果能提供負載均衡能力和自動最佳化能力，則是對整個系統性能具有莫大的好處。
2. 數據可靠性
在系統發生任意故障(包括作業系統、資料庫引擎、硬碟或磁碟陣列或存儲網路等故障)條件下數據丟失的可能性。有的系統從設計原理上注定了必然會存在理論上的數據丟失可能性，而有的系統因為冗餘設計原理，可以保證理論上的數據零丟失。用容災領域的術語來講，這類似於RPO(Recovery Point Objective)，但是不完全等同於RPO。
3. 服務可用性
在系統發生任意故障(包括作業系統、資料庫引擎、硬碟或磁碟陣列或存儲網路等故障)條件下整個系統停止對外提供數據服務的可能性。與上面的資料庫可靠性緊密關聯，如果一個系統從理論上存在數據丟失的可能性，那么這樣的系統必然會導致整個系統的服務停止。同樣地，用容災領域的術語來講，這類似於RTO(Recovery Time Objective)，但是也同樣不能完全等同於RTO。
三.資料庫集群的分類
在市場上，資料庫集群是一個籠統的名詞，沒有一個權威的定義，各市場參與者往往是各取所需，推出各種特色的資料庫集群解決方案。一般地具有下列四種集群方案：
1．基於串列數據複製技術
串列複製技術，本來是用於數據傳送和數據備份的，離人們熟悉的“資料庫集群”的概念有一定的距離。但是由於計算機軟硬體技術和網路通訊技術的快速發展，使得利用這種概念和技術構成的“資料庫集群”有了一定的可行性。此類集群，又可以分兩類:
a.串列異步複製
此種方式是數據的異步串列複製。主要採用資料庫事務日誌傳送或者硬碟數據塊傳送技術來實現，SQL Server自帶的複製、鏡像和SQL2012新出的AlwaysON(備機可讀)以及第三的一些鏡像Mirror技術都是屬於此類產品，此類技術和產品本質上就是數據備份技術和產品。下列以事務日誌傳送(Log Shipping)為例來說明。主資料庫完成事務處理後，生成事務處理日誌，日誌記錄通過FIFO佇列，進入備份資料庫處理，從而得到備份數據。此種方式的缺陷在於：
a) 主資料庫並行處理事務而日誌拷貝是串列的，而備份資料庫處理日誌記錄也是串列的。因此，FIFO佇列的溢出隨時可能發生。一旦發生，佇列必須重建，從而需要重新建立備份資料庫。此種方法對於一般客戶來講是不可行的。
b) 由於日誌拷貝是異步的，主備資料庫不是實時一致，兩者之間存在“時間差”，因此如果用備份資料庫作負荷均衡，這樣的套用存在邏輯上的漏洞，可能會發生數據錯亂。
c) 由於主備數據存在時間差, 主資料庫一旦發生事故，理論上一定會丟失數據。在這種情況下，要么需要手工恢複數據庫，這會消耗大量的人工成本，或者數據根本就不能恢復。
d) 對主機的性能影響，根據測試一般在15%到25%之間。
b.串列同步複製
此類集群往往是由昂貴的專用軟硬體構成的，原理圖如下：
此類系統採用專用的高速網路和軟體技術，將每個資料庫的請求，通過同步複製的方式，同步在主備兩台資料庫伺服器上執行正確後，才將結果返回給資料庫客戶。此系統的特點是：
a) 主資料庫被強迫與備份資料庫同步串列處理，因此性能受到限制。
b) 主備資料庫中任意一個出現問題，都會迫使事務處理交易回滾，因此整個系統的可靠性比單機系統降低了一半。
c) 由於以上問題，這種備份方式只適用於近距離光纖網路（5英里）。
d) 專用系統造價昂貴，又加上述明顯缺陷，因此市場上很少被採用。
2．基於共享存儲的雙機容錯技術
從技術適應性的角度講，雙機容錯比較適合於無狀態套用，或者狀態信息較少的套用切換，以此達到套用級的高可用性目的，其實並不適合於資料庫級的套用切換。
此種結構往往是兩個伺服器共享一個磁碟陣列，這裡兩個伺服器共享一個虛擬的IP供資料庫客戶使用，形成一個單一的邏輯資料庫映象。此種所謂的資料庫集群的目的是，一旦主機系統出現問題，備份系統通過心跳機制的檢測，完成從主機系統到備份系統的切換。這種方案在市場上被稱為“雙機集群”或者“雙機熱備”，簡稱參見“雙機”，但微軟稱之為“故障轉移集群”。它有下列特點：
a. 此種高可用性解決方案只是無狀態系統(典型的如Web伺服器)的普通容錯切換思想在資料庫領域的套用。
b. 此系統本身只有一個單一的數據映象，數據儲存在共享的磁碟陣例上，因此共享的磁碟陣列成為了整個系統的單點錯誤源。
c. 由於是單一數據映象，因此必須採用通常的複製或備份方法獲取第二份數據，以保證數據的安全性。因此所有複製或備份方法的缺點，此類系統全部存在。
d. 主機系統和備份系統之間是沒有任何負載均衡關係的，在正常情況下，備份系統是閒置在那裡，因此對用戶來說是一種投資浪費。
e. 在錯誤切換的時候，往往存在切換時間長，而且更嚴重的是可能會存在丟失用戶交易數據丟失的現象，結果導致系統被迫停止服務，或者需要人工修複數據，或者數據永遠找不回來。
3．以Oracle RAC為代表的系統
RAC的英文全稱是：Real Application Cluster(真正的套用級集群)。我們需要關注的是“套用級”。為了緩解資料庫系統日益增長的性能壓力，Oracle公司推出了RAC系統。它基本結構如下：
此類系統，專門是針對資料庫性能問題而提出的。採用共享磁碟陣列的方式，因此在結構上和上述雙機容錯相似，不同的地方在於此系統中的資料庫節點之間採用的不是簡單的心跳檢測，而是Oracle公司自己定義的一套複雜的信息交換協定，以此來動態分配來自資料庫客戶端的請求。它的特點是：
a. 是個套用級的集群，也就是針對Oracle的資料庫管理系統(因為資料庫管理系統對於作業系統來講，就是一個“應用程式”，因此被稱為“套用級集群”)，專門為提高資料庫性能而設計。
b. 此系統本身只有一個單一的數據映象，數據儲存在共享的磁碟陣例上，因此享的磁碟陣例成為了整個系統的單點錯誤源。
c. 管理配置複雜。
d. 由於是單一數據映象，因此必須採用通常的複製或備份方法獲取第二份數據，以保證數據的安全性。因此所有複製或備份方法的缺點，此類系統全部存在。
e. 由於資料庫系統本身具有高I/O的特性，因此，RAC系統里，磁碟I/O是提高性能的關鍵地方。
f. 依據不同的資料庫套用，有的性能有所提升，有的性能可能會反而下降。
套用
一．基於實時數據同步技術
基於此技術構造的資料庫集群是市場上的新興力量，它又具有兩類，分別是：
a.具有獨立網關
下面以DBTwin為例來說明其技術特點。
DBTwin採用了冗餘設計原理，對於來自客戶端的請求，請求被分成兩類：查詢請求和數據更新請求。對於數據更新請求，集群內部各節點之間保持數據的實時同步一致；對於數據的查詢請求，則可以在集群各節點之間負載均衡執行。它的特點是：
a) 負載均衡的單元是客戶端的每個獨立請求，這點除了Oracle RAC集群，是市場上獨有的。
b) 實時冗餘一致的多份數據，從理論上講實現了數據的零丟失。
c) 由於可以做到數據零丟失，因此在系統發生任意故障條件下，可以做到系統的對外服務不停止。
d) 此系統使用了專用高速數據同步技術，根據測試，數據同步速度能SQL Server的鏡像相等。
e) 此系統的缺點是數據同步需要花費代價,節點數量受到限制，一般2到4個節點為宜。
f) 此系統從巨觀上提升了整個系統的性能。
b.將調度節點集成於資料庫引擎
下面以Moebius來說明其技術特點。
任何在資料庫和應用程式之間引入的中間件都同時引入了單點故障點，如果中間件（網關）出現了故障，則資料庫集群就會形同虛設。因此Moebius在集群中的每個節點上都存在於嵌入於資料庫引擎的分發代理，當前負責調度的分發代理出現故障時，分發代理會故障轉移到集群中的其他節點，從而避免了使用網關架構所引入的單點故障點，除此之外，該類產品的特點是：
a) 負載均衡是基於每個客戶端的獨立請求，默認規則是將查詢優先分發到集群中負載低的伺服器，也可以自定義規則，將某些特定業務分發到集群中的某一台，比如將報表相關的查詢分發給集群中的特定伺服器。
b) 採用Share-Nothing架構，對數據進行冗餘，從而保證了數據的安全性
c) 資料庫同步機制採用日誌Redo的方式，在日誌同步之前對日誌進行壓縮，保證了同步效率
d) 在集群中任意節點出現故障時，會被自動剝離出節點，由剩餘運行正常的節點繼續提供服務，從而保證了最小停機時間
e) 負載均衡集群從巨觀上提高了吞吐量和性能
f) 該類集群不需要特殊的存儲設備，可以使用廉價的本地存儲，但由於數據冗餘，因此相較於Share-Disk架構而言，需要更多的存儲空間
c.沒有獨立網關
當前市場上也存在下列一種基於數據實時同步的集群，其拓撲結構如下圖所示：
此系統由於沒有獨立的集群網關，因此本質上簡化成了資料庫的實時備份系統，與實際的備份系統不同的是，它是工作在資料庫套用層。此系統的特點：
a) 沒有獨立的集群網關，通過主節點的轉發來實行查詢的負載均衡。在系統壓力大的情況下，集群主機會形成性能瓶頸，無論是CPU、記憶體還是網路頻寬，也可能是OS等系統核心資源，都容易因到達臨界狀態而形成瓶頸。
b) 各節點數據實時一致，對於數據容錯有利。
c) 對客戶端沒有二進制透明。
d) 負載均衡單元是資料庫連線。也就是說，在客戶端登入資料庫的時候，靜態地指定連線到某個集群節點，此後此連線上的全部請求一律傳送到該資料庫上，因此在特殊情況下，可能會出現這樣的場景：所有客戶端的連線集中在集群主機上，這時候，集群主機不但承擔了客戶端的所有查詢，還需要實時同步數據到所有的集群從機，即集群主機的CPU為100%，而集群別的節點CPU可能為0%，這樣整個系統的性能會受到嚴重影響。
e) 由於使用的是分散式事務機制(MSDTC)確保數據的實時一致性，因此數據同步的性能比較慢，根據測試,會比SQL Server鏡像慢好幾倍。
f) 同樣地，此集群的節點數量也受到限制，也是以2到4個節點為宜。
