數據庫集群方案及Oracle RAC架構分析
應對業務量的不斷增加場景通常有兩個大方向,一種是縱向擴展,也就是增加單臺服務器的CPU計算能力、內存容量和磁盤承載能力等;另外一種是橫向擴展,也就是通過增加服務器的數量來增加處理能力。前者存在業務中斷和擴展上限等諸多的問題,特別是互聯網業務的迅猛發展,單臺服務器幾乎無法滿足業務負載要求,因此目前比較流行的方式橫向擴展的方式。
1. 數據庫集群
數據庫的橫向擴展是通過數據庫集群實現的。數據庫集群也有兩種主要形式,一種是主備(主從)架構,也就是只有一臺服務器上的數據庫可以訪問,另一個(多個)服務器上數據庫不能訪問或者只能進行讀操作。另外一種是多活架構,這種架構中所有服務器都可以對外提供服務(可同時讀寫)。
當前市面上大部分數據庫是主從架構,比如MySQL和SQL Server等。如圖1是大名鼎鼎的MySQL數據庫的主從復制原理圖。主從復制是通過重放binlog實現主庫數據的異步復制。由于從binlog獲取數據并重放與主庫寫入數據存在時間延遲,因此從庫的數據總是要滯后主庫。這個也是主從架構的缺點,也就是無法保證數據的分布式一致性。主庫宕機的情況下可能會丟失一部分數據。
圖1 MySQL主從復制
2. 分區多活集群
多活架構是集群中的節點可以同時對外提供服務。根據集群中節點是否可以共享數據,多活架構又分為兩種。一種是非共享數據的多活,該種情況下集群節點不能共享數據,每個節點負責不同的數據。比如將數據庫表以主鍵ID進行劃分(比如取模),不同節點負責不同的區域。目前這種多活方案可以通過數據庫中間件實現,比如開源的Mycat等。
圖2 基于Mycat的多活架構
如圖2所示是基于Mycat的多活數據庫集群,這里面主要劃分為2個區域,每個區域通過主備保證可用性和分攤負載。具體策略可以采用取模的方式,比如主鍵ID為1,3,5,7...時數據存儲在左邊主庫中;2,4,6,8...時數據存儲在右邊主庫中。
由于數據的隔離性,上述訪問存在一個主要問題就是擴容相對困難。當需要增加集群節點數量的時候,就需要重新劃分數據的存儲位置,從而需要做大量的數據遷移。這樣,不僅僅操作復雜,而且增加了出現問題的風險。
3. 共享存儲多活集群(Oracle RAC)
另外一種多活架構是共享存儲集群架構,比較典型的就是Oracle RAC(全稱Oracle Real Application Cluster)。在該架構中集群中多個節點運行的是同一個數據庫實例,數據完全一致,并且用戶層面無論從那個節點訪問,獲取到的數據都是相同的。如圖3是Oracle RAC的示意圖,通過3個節點構成一個集群,它們共享數據。
圖3 Oracle RAC示意圖
為了保證整個集群的可用性,Oracle RAC在部署的時候對硬件有比較多的要求。在網絡層面,Oracle RAC總共有3個網絡系統,分別是外部訪問網絡、內部私有網絡和存儲網絡。外部訪問網絡不用多少,相信大家都理解。內部私有網絡則主要用來進行Oracle集群內部使用,包括數據傳輸、心跳和集群管理等。這部分網絡在部署的時候要求雙交換機和雙物理鏈路,保證不會因為鏈路故障導致集群異常。后面是存儲網絡,存儲網絡用于RAC集群訪問存儲資源,這部分也是鏈路冗余的。
圖4 Oracle RAC物理部署圖
為了更加深入的理解Oracle RAC我們看一下其內部軟件模塊的組成。整個數據庫層面沒有太多差異,這里面主要多出了如下內容:虛擬IP(VIP)、ASM、Clusterware和仲裁磁盤。這些新組件配合起來完成了Oracle的多活集群功能。
虛擬IP是應用訪問數據庫的入口,該IP并不與任何服務器綁定,而是可以在集群的任意服務器間漂移。由于具有這個特性,當出現服務器宕機等情況時,數據集集群可以保證通過相同的接口對外提供服務。
圖5 Oracle RAC軟件模塊圖
ASM與Clusterware實現了集群管理功能,其中ASM實現對磁盤的管理,避免同時訪問磁盤導致數據不一致的風險,而Clusterware則用于管理Oracle集群的軟件進程及資源調度。
仲裁磁盤用于集群中服務器的異常判斷,集群中的節點通過定時更新仲裁磁盤中特定區域的數據標示自身的健康狀態。其它節點可以根據該數據判斷該節點是否宕機。