數據庫集羣

這裏有兩個關鍵點：

1. 兩台或者多台數據庫服務器：如果只有一台數據庫服務器是不能稱其為集羣的。

2. 透明的服務：集羣向客户端提供的服務與單機系統向客户端提供的服務，從通訊協議上保持二進制兼容。

1.同步

數據庫客户端發出數據更新請求後，要等集羣的每個節點全部更新後，才給客户端返回結果。

2.異步

數據庫客户端發出數據更新請求後，接受請求的節點(這裏往往是主數據庫)立馬給客户端返回結果，被更新的數據則會在接下來的某個時間裏被複制傳輸到集羣的其它節點上(弱一致性處理)。

3.基於連接的負載均衡

此種負載均衡實現技術比較簡單，就是在客户端發起登陸的時候，按照某種負載均衡算法，選擇登陸到集羣某台數據庫，此後所有客户端的請求全部會發送到此數據庫上。

4.基於請求的負載均衡

此種負載均衡實現技術比較複雜，但是功能強大，就是在客户端發起登陸的時候，集羣網關會同時登錄到集羣各節點數據庫，此後所有的客户端請求，經過集羣網關的分析被分成兩類，查詢請求根據負載均衡算法挑選一個節點執行，數據更新請求則由主機執行並實時同步數據到集羣各節點。

一.與分佈式數據庫系統的區別

二.數據庫集羣的技術指標

由於數據庫系統是任何一個信息系統的核心，因此除了業務邏輯之外，用户還關心下面三點：

1. 系統性能

性能問題涉及硬件、軟件、網絡、應用設計架構、代碼質量等多方面。但是數據庫集羣如果能提供負載均衡能力和自動優化能力，則是對整個系統性能具有莫大的好處。

2. 數據可靠性

在系統發生任意故障(包括操作系統、數據庫引擎、硬盤或磁盤陣列或存儲網絡等故障)條件下數據丟失的可能性。有的系統從設計原理上註定了必然會存在理論上的數據丟失可能性，而有的系統因為冗餘設計原理，可以保證理論上的數據零丟失。用容災領域的術語來講，這類似於RPO(Recovery Point Objective)，但是不完全等同於RPO。

3. 服務可用性

在系統發生任意故障(包括操作系統、數據庫引擎、硬盤或磁盤陣列或存儲網絡等故障)條件下整個系統停止對外提供數據服務的可能性。與上面的數據庫可靠性緊密關聯，如果一個系統從理論上存在數據丟失的可能性，那麼這樣的系統必然會導致整個系統的服務停止。同樣地，用容災領域的術語來講，這類似於RTO(Recovery Time Objective)，但是也同樣不能完全等同於RTO。

在市場上，數據庫集羣是一個籠統的名詞，沒有一個權威的定義，各市場參與者往往是各取所需，推出各種特色的數據庫集羣解決方案。一般地具有下列四種集羣方案：

串行復制技術，本來是用於數據傳送和數據備份的，離人們熟悉的“數據庫集羣”的概念有一定的距離。但是由於計算機軟硬件技術和網絡通訊技術的快速發展，使得利用這種概念和技術構成的“數據庫集羣”有了一定的可行性。此類集羣，又可以分兩類:

a.串行異步複製

此種方式是數據的異步串行復制。主要採用數據庫事務日誌傳送或者硬盤數據塊傳送技術來實現，SQL Server自帶的複製、鏡像和SQL2012新出的AlwaysON(備機可讀)以及第三的一些鏡像Mirror技術都是屬於此類產品，此類技術和產品本質上就是數據備份技術和產品。下列以事務日誌傳送(Log Shipping)為例來説明。主數據庫完成事務處理後，生成事務處理日誌，日誌記錄通過FIFO隊列，進入備份數據庫處理，從而得到備份數據。此種方式的缺陷在於：

a) 主數據庫並行處理事務而日誌拷貝是串行的，而備份數據庫處理日誌記錄也是串行的。因此，FIFO隊列的溢出隨時可能發生。一旦發生，隊列必須重建，從而需要重新建立備份數據庫。此種方法對於一般客户來講是不可行的。

b) 由於日誌拷貝是異步的，主備數據庫不是實時一致，兩者之間存在“時間差”，因此如果用備份數據庫作負荷均衡，這樣的應用存在邏輯上的漏洞，可能會發生數據錯亂。

c) 由於主備數據存在時間差, 主數據庫一旦發生事故，理論上一定會丟失數據。在這種情況下，要麼需要手工恢復數據庫，這會消耗大量的人工成本，或者數據根本就不能恢復。

d) 對主機的性能影響，根據測試一般在15%到25%之間。

b.串行同步複製

此類集羣往往是由昂貴的專用軟硬件構成的，原理圖如圖1：

此類系統採用專用的高速網絡和軟件技術，將每個數據庫的請求，通過同步複製的方式，同步在主備兩台數據庫服務器上執行正確後，才將結果返回給數據庫客户。此係統的特點是：

a) 主數據庫被強迫與備份數據庫同步串行處理，因此性能受到限制。

b) 主備數據庫中任意一個出現問題，都會迫使事務處理交易回滾，因此整個系統的可靠性比單機系統降低了一半。

c) 由於以上問題，這種備份方式只適用於近距離光纖網絡（5英里）。

d) 專用系統造價昂貴，又加上述明顯缺陷，因此市場上很少被採用。

2．基於共享存儲的雙機容錯技術

從技術適應性的角度講，雙機容錯比較適合於無狀態應用，或者狀態信息較少的應用切換，以此達到應用級的高可用性目的，其實並不適合於數據庫級的應用切換。

此種結構往往是兩個服務器共享一個磁盤陣列，這裏兩個服務器共享一個虛擬的IP供數據庫客户使用，形成一個單一的邏輯數據庫映象。此種所謂的數據庫集羣的目的是，一旦主機系統出現問題，備份系統通過心跳機制的檢測，完成從主機系統到備份系統的切換。這種方案在市場上被稱為“雙機集羣”或者“雙機熱備”，簡稱參見“雙機”，但微軟稱之為“故障轉移集羣”。它有下列特點：

a. 此種高可用性解決方案只是無狀態系統(典型的如Web服務器)的普通容錯切換思想在數據庫領域的應用。

b. 此係統本身只有一個單一的數據映象，數據儲存在共享的磁盤陣例上，因此共享的磁盤陣列成為了整個系統的單點錯誤源。

c. 由於是單一數據映象，因此必須採用通常的複製或備份方法獲取第二份數據，以保證數據的安全性。因此所有複製或備份方法的缺點，此類系統全部存在。

d. 主機系統和備份系統之間是沒有任何負載均衡關係的，在正常情況下，備份系統是閒置在那裏，因此對用户來説是一種投資浪費。

e. 在錯誤切換的時候，往往存在切換時間長，而且更嚴重的是可能會存在丟失用户交易數據丟失的現象，結果導致系統被迫停止服務，或者需要人工修復數據，或者數據永遠找不回來。

RAC的英文全稱是：Real Application Cluster(真正的應用級集羣)。我們需要關注的是“應用級”。為了緩解數據庫系統日益增長的性能壓力，Oracle公司推出了RAC系統。它基本結構如下：

此類系統，專門是針對數據庫性能問題而提出的。採用共享磁盤陣列的方式，因此在結構上和上述雙機容錯相似，不同的地方在於此係統中的數據庫節點之間採用的不是簡單的心跳檢測，而是Oracle公司自己定義的一套複雜的信息交換協議，以此來動態分配來自數據庫客户端的請求。它的特點是：

a. 是個應用級的集羣，也就是針對Oracle的數據庫管理系統(因為數據庫管理系統對於操作系統來講，就是一個“應用程序”，因此被稱為“應用級集羣”)，專門為提高數據庫性能而設計。

b. 此係統本身只有一個單一的數據映象，數據儲存在共享的磁盤陣列上，因此共享的磁盤陣列成為了整個系統的單點錯誤源。

c. 管理配置複雜。

d. 由於是單一數據映象，因此必須採用通常的複製或備份方法獲取第二份數據，以保證數據的安全性。因此所有複製或備份方法的缺點，此類系統全部存在。

e. 由於數據庫系統本身具有高I/O的特性，因此，RAC系統裏，磁盤I/O是提高性能的關鍵地方。

f. 依據不同的數據庫應用，有的性能有所提升，有的性能可能會反而下降。

基於此技術構造的數據庫集羣是市場上的新興力量，它又具有兩類，分別是：

下面以DBTwin為例來説明其技術特點。

DBTwin採用了冗餘設計原理，對於來自客户端的請求，請求被分成兩類：查詢請求和數據更新請求。對於數據更新請求，集羣內部各節點之間保持數據的實時同步一致；對於數據的查詢請求，則可以在集羣各節點之間負載均衡執行。它的特點是：

a) 負載均衡的單元是客户端的每個獨立請求，這點除了Oracle RAC集羣，是市場上獨有的。

b) 實時冗餘一致的多份數據，從理論上講實現了數據的零丟失。

c) 由於可以做到數據零丟失，因此在系統發生任意故障條件下，可以做到系統的對外服務不停止。

d) 此係統使用了專用高速數據同步技術，根據測試，數據同步速度能SQL Server的鏡像相等。

e) 此係統的缺點是數據同步需要花費代價,節點數量受到限制，一般2到4個節點為宜。

f) 此係統從宏觀上提升了整個系統的性能。

下面以Moebius來説明其技術特點。

任何在數據庫和應用程序之間引入的中間件都同時引入了單點故障點，如果中間件（網關）出現了故障，則數據庫集羣就會形同虛設。因此Moebius在集羣中的每個節點上都存在於嵌入於數據庫引擎的分發代理，當前負責調度的分發代理出現故障時，分發代理會故障轉移到集羣中的其他節點，從而避免了使用網關架構所引入的單點故障點，除此之外，該類產品的特點是：

a) 負載均衡是基於每個客户端的獨立請求，默認規則是將查詢優先分發到集羣中負載低的服務器，也可以自定義規則，將某些特定業務分發到集羣中的某一台，比如將報表相關的查詢分發給集羣中的特定服務器。

b) 採用Share-Nothing架構，對數據進行冗餘，從而保證了數據的安全性

c) 數據庫同步機制採用日誌Redo的方式，在日誌同步之前對日誌進行壓縮，保證了同步效率

d) 在集羣中任意節點出現故障時，會被自動剝離出節點，由剩餘運行正常的節點繼續提供服務，從而保證了最小停機時間

e) 負載均衡集羣從宏觀上提高了吞吐量和性能

f) 該類集羣不需要特殊的存儲設備，可以使用廉價的本地存儲，但由於數據冗餘，因此相較於Share-Disk架構而言，需要更多的存儲空間

當前市場上也存在下列一種基於數據實時同步的集羣，其拓撲結構如圖2所示：

此係統由於沒有獨立的集羣網關，因此本質上簡化成了數據庫的實時備份系統，與實際的備份系統不同的是，它是工作在數據庫應用層。此係統的特點：

a) 沒有獨立的集羣網關，通過主節點的轉發來實行查詢的負載均衡。在系統壓力大的情況下，集羣主機會形成性能瓶頸，無論是CPU、內存還是網絡帶寬，也可能是OS等系統內核資源，都容易因到達臨界狀態而形成瓶頸。

b) 各節點數據實時一致，對於數據容錯有利。

c) 對客户端沒有二進制透明。

d) 負載均衡單元是數據庫連接。也就是説，在客户端登陸數據庫的時候，靜態地指定連接到某個集羣節點，此後此連接上的全部請求一律發送到該數據庫上，因此在特殊情況下，可能會出現這樣的場景：所有客户端的連接集中在集羣主機上，這時候，集羣主機不但承擔了客户端的所有查詢，還需要實時同步數據到所有的集羣從機，即集羣主機的CPU為100%，而集羣別的節點CPU可能為0%，這樣整個系統的性能會受到嚴重影響。

e) 由於使用的是分佈式事務機制(MSDTC)確保數據的實時一致性，因此數據同步的性能比較慢，根據測試,會比SQL Server鏡像慢好幾倍。

f) 同樣地，此集羣的節點數量也受到限制，也是以2到4個節點為宜。