點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

數據庫高可用是一個復雜的系統工程，本文主要介紹了幾種數據庫高可用的基本技術：HADR、 HACMP、 數據復制，存儲層容災和DPF高可用。并結合實踐實際，分別論述了它們的適用場景和技術特征。在不同場景，不同的業務連續性級別下，我們可以組合使用這幾種技術，以實現從存儲，網絡，系統，數據庫到應用的高可用技術。

一. DB2 HADR

HADR全稱為High Availability Disaster Recovery ，是IBM DB2數據庫上的數據庫級別的高可用性數據復制機制，最初被應用于Informix數據庫系統中，稱為High Availability Data Replication(HDR)，IBM收購Informix之后，這項技術就應用到了新的DB2發行版中。HADR有一主一備數據庫，在9.7之前備機不可讀，9.7之后備機可讀可以降低主數據庫的負擔。(這個Oracle的DataGuard邏輯備機可讀做的就很好，但是為什么IBM會落后呢?)

在數據專線帶寬足且穩定的情況下，在要求主備完全數據無損的時候，推薦用同步方式傳送，或者能容忍一定少量的損失，可以用準同步，但是推薦在在生產中心和同城的災備中心之間（LAN或者MAN），如果在1000公里以上帶寬和時延都沒什么保障的話，比如北京和上海，最好還是用異步的方式，如果更差或者對OLTP的實時性要求較高還可以用超級異步，當然這對流水的損失要有一定的容忍度。

HADR一個很不好的特點是不能用于DPF，只能適合單分區數據庫，這就限制了數據庫在高可用下的規模以及并發性。HADR從一些實際應用來看，切換速度要比DG要快，而且切換出現故障的可能性要小些。

談到HADR絕對不能離開DataGuard，實際上中國人民銀行對兩地三中心的規定就非常適合DataGuard的兩個備用數據庫的方式，生產中心用主數據庫，同城災備中心用物理備用，異地災備中心用邏輯備用。Oracle的DataGuard在網絡故障恢復之后可以自動同步。

HADR有一個弱點就是不能進行數據壓縮和加密，如果沒有VPN就麻煩了，但是HADR可以集成第三方的SSH軟件。而DG本身就集成了SSH進行壓縮和加密功能。HADR最要命的是不能支持異構數據庫的復制，當然這個也不是他的主要場景。

DB2異地災備用HADR的比較多，在9.7之前用HADR的話備機不可讀很麻煩，所以有的時候就要用Q復制，這樣主備都可讀，如果要零容忍和短切換時間的話，用HADR比較靠譜。

二. SQL復制和Q復制

SQL復制主要應用于相同局域網內。Q復制遠程好一點，因為在網絡比較差的時候，WebSphere MQ可以緩存一段時間數據。Q復制一般結合HADR比較多，用于實現數據遠程異地復制（比如中國煙草總公司容災中心）。Q復制可以通過分析事務日志來獲取系統變化，對系統的性能影響比較小。是高效率的復制方案。但是Q復制只是對DB2支持的比較好，對Oracle嘛就那樣，其他的數據庫支持的都不好。Q復制也支持表級別的復制。Inforsphere CDC（原來叫Data Mirror）支持多種數據庫的表復制。

Oracle也有GoldenGate，這個熟悉的人也知道，支持ORACLE最好，其他的嘛不好說。但是CDC在表依賴上有些復雜，會有點問題，需要具體處理。

三、 HACMP

HACMP Cascading模式中，有主又備，節點有優先級，資源組在優先級搞的節點運行，高優先級節點故障恢復之后，資源組重新歸位。

Cascading用于主備機硬件性能有較大差別的環境，節約成本，這個對于不差錢的運營商、航空、銀行、政府絕對不會采用。Rotating模式中，有主有備，節點優先級相同，資源組在先啟動節點運行，節點故障恢復后，資源組不會前移。Rotating適用于對可用性要求較高的場景，電信行業的數據業務，增值業務，彩鈴等產品多采用這種方式。

Concurrent模式無主備，節點優先級同，資源組在所有節點運行，節點故障不會導致資源組切換，故障節點恢復后，資源組恢復可用，不發生前移，適合大容量據點。Concurrent模式一般和Oracle的RAC或者并行服務器（OPS）合用較多。

電信業務中，增值特服大容量據點采用，智能網、BOSS也有應用，這種模式的結合和PureScale十分類似。但是HACMP中數據庫只有一份，如果數據庫被破壞，主機和操作系統還好也沒毛用，所以還要結合HADR才更安全。HACMP一般是由網卡和機器Down機所觸發的，軟件改動不知道是否能夠觸發呢？我也不是很清楚。

其實HADR，HACMP在本地數據中心的效果最好，如果是異地的話最好是使用HAGEO，或者在存儲層的做，因為軟件層面效率并不是很高而且還很占主機的系統資源和網絡帶寬，當然不同公司的選擇和考慮是不一樣的。

四、DPF的高可用方案

關于DPF，其實DPF本身并沒有高可用性的方案。但是由于多節點技術，在某些條件滿足的情況下有一定程度上的容災。要求Catalog節點不能Down，如果非關鍵節點Down，DPF數據庫還是可以訪問的。

但是如果你要某些表可訪問，只有在該表所在表空間所覆蓋的分區節點沒有Down。DPF節點Down有幾種情況，如果是操作系統或者網絡故障，可以通過HACMP恢復，如果是節點數據庫損壞，就沒有辦法了。其實DPF這么多節點也是引入了故障點的概率，所以OLTP在沒有HA保障的話，是不敢建在DPF上的。

DPF在建庫的時候，最好規劃好關鍵節點的HA和備份工作，定期檢查表，表空間的分布，并記錄下來，有問題可以迅速定位和恢復。表空間級別的備份在DPF還是很重要的。

如果資金保障比較充足的話，建議給所有幾點都做HA，因為一般數據庫本身導致的可用性問題要比OS和硬件網絡導致的要少很多。DPF跨節點表和表空間特別多，千萬不要因為節點本身的問題造成表空間不可用那個。

五、存儲層的容災

談到高可用，不能離開存儲層的容災，比如磁盤鏡像技術，和第三方的備份技術。當然，Everyone都知道，存儲層的技術避免不了宕機的，要有一段切換時間。

SRDF一種比較復雜技術。SRDF在國外應用的非常多，國內銀行也開始應用。SRDF可以實現分層的數據備份和恢復?？梢钥绱髽?#xff0c;可以實現全球的數據復制。同樣的，和HADR和DG類似，也有同步，準同步和異步的模式。覆蓋的距離可以多達幾千公里，但是因為無需考慮類似于HADR的實時性交易問題，另外SRDF支持所有的主機和數據庫系統。這個一般在數據中心搬遷的時候用的比較多。

如果在距離比較近的時候比如數公里的距離，可以使用裸光纖，如果較遠的話，就要用華為或者Cisco的DWDM進行光纖延伸，根據數據傳輸的需求制定線路的速率。SRDF非常昂貴，如果我們的數據和客戶交易不強相關的話，就可以使用笨笨的磁帶拷貝搬遷方法，建立應用系統，然后再用SRDF傳輸實時要求高的數據，啟動新數據中心的系統，切換網絡。

Veritas大家也非常了解了，論壇上用過的人該很多。通過 Veritas的BMR技術，可以直接連操作系統帶數據全部備份到數據中心。更為強悍的是，無需LAN的SAN多磁盤并發備份，減少對網絡帶寬的影響。通過BMR可以制作啟動光盤，進行系統恢復。針對于不同的數據庫還提供相應的agent，提供在線熱備份技術。

六、高可用的網絡、電力和制度方面

網絡就不用說了，網卡漂移，多子網，冗余光纖等。一般來說，生產中心和災備中心之間要有四個交換機，以及四個存儲層主機實現高可用，并配備多路光纖。電力的話，要有UPS備用電源和發電機。數據中心的電力和網絡一定要求運營商提供第一流的保障級別，否則誰都付不起責任。當然還有自來水、便利的交通等等方面。

大規模的電信運營商、銀行都有非常成熟的制度和流程。中國人民銀行也有非常詳盡的規范。各銀行也制定自己的一些細節規定。制度一定要控制濫用權限、各種誤操作、以及指明應急時候的操作。前面的兄弟也有一些闡述，比如雙保險，及時進行災備切換演練，整體級別的，應用軟件級別的都要有。數據中心建成的時候，要各種切換和場景都要嘗試。

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

【精彩推薦】

• 原創|OpenAPI標準規范

• 如此簡單| ES最全詳細使用教程

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 微服務下如何解耦？對于已經緊耦合下如何重構？

• 如何構建一套高性能、高可用、低成本的視頻處理系統？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交
  

點個贊+在看，少個 bug?????

總結

以上是生活随笔為你收集整理的数据库高可用(HA)技术有哪些？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。