資料庫叢集系統研究系列（2）-現存的資料庫的解決方案的原了解析

資料庫

資料庫叢集

此種方式是異步串行複制或日志拷貝(Log Shipping)。主資料庫完成事務處理後，生成事務處理日志，日志記錄通過FIFO 隊列，進入備份資料庫處理，進而得到備份資料。此種方式的缺陷在于：

a. 複制隊列溢出問題：主資料庫是并行處理而日志拷貝是串行的，是以備份資料庫處理日志記錄也是串行的。是以，FIFO 隊列的溢出随時可能發生。一旦發生，隊列必須重建，進而需要重建立立備份資料庫。此種方法對于一般客戶來講是不可行的。

b. 或者為了避免隊列溢出，必須保證主資料庫處理事務的速度小于備份資料庫，這樣将嚴重束縛主資料庫的性能發揮。

c. 由于日志拷貝是異步的，主備資料庫不是實時一緻。是以無法用備份資料庫作負荷均衡。

d. 由于主備資料庫永遠不一緻, 主資料庫一旦發生事故，就一定會丢失資料。在這種情況下，要麼需要手工恢複資料庫，這會消耗大量的人工成本，或者資料根本就不能恢複。

2.串行同步複制

此類叢集往往是由昂貴的專用軟硬體構成的，原理圖如下：

此類系統采用專用的高速網絡和軟體技術，将每個資料庫的請求，通過同步複制的方式，同步在主備兩台資料庫伺服器上執行正确後，才将結果傳回給資料庫客戶。

此系統的特點是：

a. 主資料庫被強迫與備份資料庫同步串行處理，是以性能受到限制。

b. 主備資料庫中任意一個出現問題，都會迫使事務處理交易復原，是以整個系統的可靠性比單機系統降低了一半。

c. 由于以上問題，這種備份方式隻适用于近距離光纖網絡（5 英裡）。

d. 專用系統造價昂貴，又加上述明顯缺陷，是以市場上很少被采用。

基于雙機容錯技術

從技術适應性的角度講，雙機容錯比較适合于無狀态應用，或者狀态資訊較少的應用切換，以此達到應用級的高可用性目的，其實并不适合于資料庫級的應用切換。

此種結構往往是兩個伺服器共享一個磁盤陣列，這裡兩個伺服器共享一個虛拟的IP 供資料庫客戶使用，形成一個單一的邏輯資料庫映象。

此種所謂的資料庫叢集的目的是，一旦主機系統出現問題，備份系統通過心跳機制的檢測，完成從主機系統到備份系統的切換，它有下列特點：

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

b. 此系統本身隻有一個單一的資料映象，資料儲存在共享的磁盤陣例上，是以共享的磁盤陣例成為了整個系統的單點錯誤源。

c. 由于是單一資料映象，是以必須采用通常的複制或備份方法擷取第二份資料，以保證資料的安全性。是以所有複制或備份方法的缺點，此類系統全部存在。

d. 主機系統和備份系統之間是沒有任何負載均衡關系的，在正常情況下，備份系統是閑置在那裡，是以對使用者來說是一種投資浪費。

e. 在錯誤切換的時候，往往存在切換時間長，而且更嚴重的是存在丢失使用者交易資料丢失的現象，結果導緻系統被迫停止服務，或者需要人工修複資料，或者資料永遠找不回來。

f. 在錯誤切換的時候，有時候會發生備份系統的資料庫啟動不了的情況，這時候，整個資料庫系統也就無法通路了，這與雙機方案本身是高可用性方案的宗旨是相抵觸的。

以RAC 為代表的系統

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

此類系統，專門是針對資料庫性能問題而提出的。采用共享磁盤陣列的方式，是以在結構上和上述雙機容錯相似，不同的地方在于此系統中的資料庫節點之間采用的不是簡單的心跳檢測，而是ORACLE 公司自己定義的一套複雜的資訊交換協定，以此來動态配置設定來自資料庫用戶端的請求。它的特點是：

a. 是個應用級的叢集，也就是針對ORACLE 的資料庫管理系統(因為資料庫管理系統對于作業系統來講，就是一個“應用程式”，是以被稱為“應用級叢集”)，專門為提高資料庫性能而設計。

b. 此系統本身隻有一個單一的資料映象，資料儲存在共享的磁盤陣例上，是以享的磁盤陣例成為了整個系統的單點錯誤源。

c. 管理配置複雜。

d. 由于是單一資料映象，是以必須采用通常的複制或備份方法擷取第二份資料，以保證資料的安全性。是以所有複制或備份方法的缺點，此類系統全部存在。

e. 由于資料庫系統本身具有高I/O 的特性，是以，RAC 系統裡，磁盤I/O 是提高性能的關鍵地方。

綜合上所述，針對資料庫系統普遍存在的三大方面的問題，上述各個技術和方案，各有不同的側重，實作的代價和複雜度也各不相同，但是它們有共同的特點是：隻解決資料庫系統的某一方面的問題，甚至在解決這方面問題的時候，同時加重了另外一個或兩個方面的問題。

相關閱讀：

<a href="http://www.agilesharp.com/showtopic-137.aspx" target="_blank">Oracle RAC vs SQL Server 第一篇: Oracle RAC 篇利弊分析</a>

<a href="http://www.agilesharp.com/showtopic-152.aspx" target="_blank">Oracle RAC vs SQL Server 第三篇: SQL Server橫向擴充方案-SODA</a>

<a href="http://www.agilesharp.com/showtopic-155.aspx" target="_blank">Oracle RAC vs SQL Server 第四篇: SQL Server橫向擴充方案-P2P</a>

<a href="http://www.agilesharp.com/showtopic-181.aspx" target="_blank">Oracle RAC vs SQL Server 第五篇: SQL Server橫向擴充方案-可伸縮的共享資料庫</a>

<a href="http://www.agilesharp.com/showtopic-199.aspx" target="_blank">Oracle RAC vs SQL Server 第六篇: Data Dependent Routing</a>

本文轉自yanyangtian51CTO部落格，原文連結： http://blog.51cto.com/yanyangtian/1152889

，如需轉載請自行聯系原作者