“數據不能丟，業務不能停”是關鍵核心業務系統的訴求，這對數據庫的高可用性提出了很高的要求。中國數據庫想要挑起大梁，服務好關鍵業務場景，必須具備強大的高可用能力，擁有相對完善的高可用解決方案，從而最大程度地保障業務的連續性。現在有哪些主流的數據庫高可用解決方案？企業該如何選擇適合的高可用解決方案？如何更好保障業務連續性？

針對以上問題，近日南大通用GBase 8s產品經營部總經理崔志偉接受了數據庫技術社區ITPUB的采訪，他表示：對業務連續性的追求沒有止境，當前國內數據庫市場有著豐富的數據庫高可用架構，企業需要根據業務場景需要來選擇合適的高可用解決方案。

數據庫高可用架構演進歷程

高可用性（HA，High Availability）是指系統在面對硬件故障、軟件崩潰、網絡問題等各種故障情況時，仍然保持運行并提供服務的能力。通過設計減少系統不能提供服務的時間，通過冗余和自動故障轉移等方法來提高系統的可用性，避免單點故障，從而確保系統的高穩定性和持續性。

早期的數據庫并沒有高可用架構，主要通過定期數據庫備份和日志歸檔等方式來提供可用性，數據庫很容易成為單點故障點，彼時高可用更多是通過操作系統層面提供集群軟件來管理包括數據庫在內的軟硬件，比如IBM高可用性集群軟件HACMP，它主要用于AIX操作系統，提供高可用性和故障轉移功能，確保關鍵業務應用的連續運行。

上個世紀90年代，隨著互聯網的興起和企業對數據依賴性的增加，高可用性成為數據庫系統設計中的一個關鍵因素。數據庫開始引入冗余和故障轉移機制，以提高系統的可靠性和可用性。

數據庫高可用架構隨著存儲、網絡等硬件技術的發展、業務需求不斷演進，從單機到主備式集群，再到共享存儲集群，再到分布式集群，出現了越來越豐富的高可用方案。

以Oracle這位行業引領者為例，陸續推出了主機HA（Highly Available）、ADG（Active DataGuard）、RAC（Real Application Cluster）、OGG（Oracle Golden Gate）等多種形式。這些高可用架構可以單獨使用，也可以組合使用，多年來，為金融機構、電信運營商的關鍵核心業務提供了穩定可靠的高可用服務。

比如，Oracle主備式高可用ADG，早期稱為DG，主節點可讀可寫，但是備節點無法提供查詢。Oracle 11g引入了Active Data Guard（ADG），允許備節點用于查詢，從而減輕主節點的負載，進一步提高了系統高可用性。后面，ADG又提供了最大保護、最大可用、最大性能三種數據保護模式，供用戶靈活選擇。

2000年發布的Oracle 9i是一個重要的里程碑，推出了Real Application Clusters（RAC）技術。RAC是屬于典型的shared-everything架構，即共享存儲集群技術，允許多個服務器共享一個數據庫實例，從而提供了高可用性和負載均衡能力。如果一個節點發生故障，其他節點可以繼續提供服務，確保系統的連續性。隨著RAC技術不斷成熟，越來越多的大型企業的核心數據庫選用了RAC技術。

在國產化替代背景下，雖然國產數據庫的技術堆棧發生了變化，但是業務對數據庫的高可用要求并不會弱化，只會越來越高。國產數據庫需要在高可用性技術上達到Oracle的同等水平甚至有所突破才能逐步實現各行業關鍵核心業務的替換。

目前，國產數據庫大多已經借鑒Oracle構建了自己的完整高可用架構，以南大通用GBase 8s數據庫為例，就有一整套對標Oracle高可用的技術棧來確保業務系統的高可用服務。

比如，GBase 8s主備式集群支持HAC和RHAC兩種集群方式。HAC是一主一備集群模式，可以根據網絡傳輸條件選擇全同步、近同步和異步三種redo log復制形式，對標Oracle ADG的最大保護、最大可用、最大性能三種工作模式。RHAC支持一主多備，采用異步傳輸機制。

GBase 8s共享存儲高可用集群SSC（對標Oracle RAC），采用共享磁盤方式實現節點高可用，數據僅存儲一份，支持多寫多讀，有效利用硬件資源，避免數據重復存儲問題，共享存儲支持磁盤陣列也支持分布式存儲。

在集中式數據庫領域，RAC共享存儲集群有較高的技術難點，被視為珠穆朗瑪峰般的存在，而國產數據庫在類RAC集群的突破無疑叩開了高端場景的大門。不過雖然很多國產數據庫擁有類RAC集群，但是能夠支持多寫多讀的并不多，很多備節點都是只讀狀態，集群吞吐量小于單機處理能力。

崔志偉指出，所有IT技術最終都要服務于業務發展。國產數據庫高可用架構已經實現了從無到有。走到了從有到優的路上，接下來，大家在不斷完善高可用方案的同時，都會向著降低主備切換時間方向努力，不斷提升業務連續性，提升集群吞吐量。

如何選擇合適的高可用方案？

可能有人說，既然業務連續性那么重要，就盡量使用更高級別的高可用架構，如果您不差錢，悉聽尊便。但現實中，即使銀行這樣非常有實力的金融機構，在構建高可用時也要反復權衡思量，不敢任性，因為高可用方案太燒錢了。無論同城災備還是異地災備，機房、網絡等都需要大量真金白銀投入。

崔志偉介紹，不同的高可用解決方案有各自的特點，他建議企業可以根據業務場景需要，結合自身資金、機房、網絡條件選擇不同的高可用解決方案。

比如主備式集群這一常見的高可用方案，比較適合小數據量，以及對數據一致性等要求不是特別嚴苛的業務場景。

一方面，主備式集群的冗余需要多存儲數據副本，會帶來額外存儲成本。另一方面，出現故障后，數據同步、主備切換需要一定的時間。如果數據量達到幾十T，會帶來較高的存儲成本，也會增大主備切換的時間窗口。此外，主備式集群的數據同步不太容易保證兩個節點的數據強一致性，很多國產數據庫會通過讀寫分離插件彌補這方面的不足。

共享存儲集群，很好地解決了存儲成本和數據強一致性問題，適合大數據量以及對數據強一致性要求較高的業務場景。

共享存儲集群用最少的硬件、最少的數據庫，實現高性能，保持業務連續性，是整體性價比較高的一個高可用方案。只不過，共享存儲集群集群比較復雜，有較高的技術門檻，需要數據庫的維護和開發人員具有比較高的專業能力。此外，共享存儲集群對硬件、數據庫軟件有較為苛刻的要求。為了實現數據強一致性，信息同步需要非常高的網絡帶寬，比如Oracle RAC心跳網絡基本萬兆起步，而Oracle一體機在內部心跳甚至會使用40GB的專業高速網絡。

崔志偉指出，一般政企客戶數據量沒有那么大的業務場景，大多會選擇主備式集群高可用方案，但是在類似金融領域需要數據強一致性的業務場景，以及大數據量（數據量超過10T、20T）的業務場景，會選擇共享存儲集群解決方案。

GBase 8s提供了相對完善的高可用解決方案供企業靈活選用，比如主備高可用HAC/RHAC、共享存儲集群高可用SSC、數據實時同步ER。

?  GBase 8s HAC集群，適用于對網絡延遲比較敏感的業務，建議同城或同機房部署，考慮到單服務器磁盤可用容量的限制，數據量不超過10T時可以采用HAC。遠距離傳輸、異地容災的業務場景，可以采用RHAC集群。由于遠距離傳輸，帶寬小，會增大網絡延遲，RHAC會通過異步檢查點機制和數據壓縮來優化對帶寬的使用。

?  GBase 8s共享存儲高可用集群SSC，是類RAC技術，支持共享存儲，保證數據的強一致性，集群為主控對等管理模式，集群節點數最多可達16個，所有節點均可讀寫。當主節點失效時，輔助節點可以升級為主控節點，保障系統的高可用。在數據量低于100TB的業務場景中，相對于分布式數據庫而言，共享存儲集群是性價比最高的高可用方案。對于數據量超過100T的業務，分布式數據庫可能比集中式數據庫更為合適。

?  GBase 8s 數據實時交換共享集群（對標OGG），內置以表為單位的數據實時同步能力，更多應用在數據交換共享場景，比如，部省市縣數據實時交換共享業務場景，商超門店等平行單位之間數據實時交換共享場景。

企業可以單獨部署主備高可用或者共享存儲集群高可用，也可以組合使用，搭建同城雙中心（SSC+HAC）、兩地三中心（SSC+HAC+RHAC）等更高級別的高可用方案。

GBase 8s兩地三中心方案

目前，GBase 8s高可用集群解決方案可以實現RPO=0，RTO＜30s，在真實業務場景中，大概10-15s就能完成主備切換。

GBase 8s高可用集群憑借出色的能力，已經服務了眾多金融、軌道交通、能源、政府等行業的關鍵核心業務，贏得了關鍵行業客戶的信賴。

比如，國家電網調度云平臺，業務數據超過50TB，采用SSC+RHAC高可用方案成功替換Oracle，通過上千公里遠程異地容災方案建設，實現本地、異地讀寫分離雙活集群秒級數據同步，數據庫對應用完全透明，最長持續運行超過600天。

深圳地鐵CLC二期與互聯網票務管理系統在生產云主中心及各站點處搭建SSC+HAC方式，實現高可用集群功能。滿足4000并發穩定運行1小時以上，千萬級數據量，毫秒級查詢響應。

某西南城商行核心系統采用SSC+HAC高可用方案，數據庫完成替換之后，持續在線運行超過760天，充分體現了GBase 8s的穩定性。

小結：追求業務連續性無止境

未來，GBase 8s將不斷優化完善其高可用方案，比如提供更細顆粒度的資源管控能力，在主節點出現故障后，鎖住受影響部分事務涉及的表，其他表依然能打開去做交易。另外，提供會話保持以及事務保持能力。在共享存儲集群中支持數據分片，減少沖突等等。

“保證客戶業務連續性最好，不論數據庫發生什么樣的故障，對客戶來講沒有感知，這是我們追求的終極目標。”崔志偉說，GBASE南大通用將持續打造用戶值得信賴的數據庫，越來越多的真實用戶場景已經將GBase 8s打磨得更穩定可靠，目前其SSC集群已經上線了幾百套，客戶的認可給了他很大的信心。

數字經濟時代，企業對業務連續性的追求永無止境。但是在有限資源的情況下，高可用也好，業務連續性也好，需要用戶和廠商共同努力，才能取得更好的效果。

“在用戶側，領導和技術團隊應該制定出合理的高可用切換目標，破開關鍵系統和高可用能力之間的強綁定，根據系統業務的真正特點去設計高可用目標。而在數據庫廠商側，則應該根據用戶的應用場景需求去優化自己產品的高可用能力，不要總是拼一個不怎么靠譜的故障切換時間。”借用白鱔老師在其文章中這段話結尾，希望在用戶與廠商共同努力下，系統高可用能力能不斷精進，業務連續性能得到更好的保障。