Oracle 高可用架構

作者： Uwe Hesse
Oracle高可用架構是我所講課程裡的一個熱門話題，本文嘗試對此話題做一個總體的說明，內容涵蓋”普通的”單例項資料庫，DataGuard，RAC以及擴充套件RAC（有時也被稱為”伸展叢集”）。Rac與Dataguard組合在一起就是Oracle公司推廣的最大可用性架構(Maximum Availability Architecture，MAA)。除這些Oracle的HA解決方案外，我還會簡單介紹一個第三方的HA解決方案（遠端映象，Remote Mirroring）。我不準備深入介紹所有這些解決方案的細節，而只是想做出一點區分的工作，並簡要介紹它們各自的優勢以及可能的缺陷。

首先，我們將考察目前為止仍然是應用最為廣泛的Oracle資料庫架構：單例項資料庫。一個Oracle資料庫總是由一個資料庫（由資料檔案、線上重做日誌控制檔案組成）與一個例項（有記憶體結構，比如資料庫高速緩衝區，以及後臺程式，例如資料庫寫程式）組成。如果我們有一個資料庫以及多個訪問這個資料庫的例項，這就是一個RAC。如果只有一個例項訪問這個資料庫，就是單例項資料庫。下圖是一個所有元件都儲存在一個伺服器上的簡單安裝版本：

將資料庫檔案放置在SAN（儲存區域網路）的配置也是目前比較常見的配置，如下圖所示：

從高可用的角度來看，這個架構是非常脆弱的：伺服器A與伺服器B都是單點故障，資料庫A與資料庫B也都是單點故障，從而這些伺服器所在的站點也是單點故障。這樣，只要其中一個單點發生故障，整個資料庫將不可用。一個”普通的”RAC就是為了解決其中的伺服器單點故障的，如下圖所示：

如果兩個伺服器的其中一個發生故障，資料庫C將仍然可用。當然，使用RAC並不僅僅是為了實現HA。在使用RAC的其它的理由中，一個比較可靠的理由是為了實現伸縮性（Scalability）：如果應用需求在將來出現增長，我們可以通過新增新的節點（Node）到叢集中來解決。另外，通過使用RAC我們還可以選擇使用服務管理（Service-Management）與負載均衡（Load Balance）。簡言之，RAC不僅僅是HA，在此詳述其它原因已經超出本文的範疇了。從HA的視角看，使用RAC的缺陷是：資料庫C以及相應的站點C是單點。如果站點C發生故障（比如火災），資料庫C將不可用。因此，將資料庫伸展到兩個站點就成為我們的選擇了，這也是通常所說的擴充套件RAC。

現在，這兩個站點就不再是單點了。資料庫D是在兩個站點之間做映象的。這個架構的缺陷是兩個站點之間的網路連線的成本。如果兩個站點之間的距離比較遠的話，這很關鍵，因為需要映象的資料量會非常大。實際上，這使得兩個站點之間的距離侷限於幾公里以內，而這與想要實現的災難保護目標之間有衝突。這時，Dataguard就隆重登場了：利用DataGuard，我們很容易就可以實現長距離的災難保護，因為，此時我們不再需要傳輸所有的資料量，而僅僅需要傳輸（相對小）的重做日誌。在下圖中，每個伺服器都像上面的伺服器A與伺服器B一樣，只有一個例項：

備用資料庫由來自主資料庫的重做日誌。 當主庫發生故障時，我們可以失敗切換（Failover）到備庫上並繼續有效工作。這個失敗切換工作可以由一個Observer（觀察員程式，通常稱為快速啟動失敗切換，Fast-Start Failover）自動實現。兩個站點之間的距離達到幾千公里（依賴於重做日誌的傳輸策略與保護級別（protection level））。如果我們將RAC與Dataguard集合起來，我們就實現了MAA。顯然，MAA是一個昂貴的解決方案，不過它也同時享有RAC與Dataguard的所有好處。

遠端映象是一個廣受歡迎的第三方HA解決方案，總體上，它的架構與下圖類似：

這時，也沒有哪個站點是單點的，類似於使用擴充套件RAC架構。這個解決方案的缺陷是：站點間的距離也是嚴格受限制的，理由與擴充套件RAC架構類似。同時，在映象進行的時候，第二個站點是無法提供服務的，這一點與上述的Oracle提供的HA解決方案不同。使用RAC時，所有的伺服器與相應的站點都可以提供服務。哪怕是使用Dataguard，備用資料庫也不僅僅是等待主庫發生故障。除此之外，它還可以提供只讀訪問服務，這將可以有效降低主庫的負載。

上圖展示了Oracle 11g的新特性”物理備用資料庫上的實時查詢”。在恢復過程中時，備用資料庫也在同時提供只讀訪問。另外，還可以在物理備庫（Physical Standby）上做離線備份（OffLoad Backup）。