高可用架構是關鍵數據庫應用必須考慮的，昨天我的文章里也說過，數據庫出故障不可怕，只要不出現業務受到嚴重影響的事故就可以了。而確保業務不出事故的方案中必然少不了數據庫的高可用架構。

早期數據庫是沒有高可用架構的，數據庫就成了著名的單點故障點。后來引入了HA，Oracle也祭出了OPS/RAC這個大殺器。98年的時候，我給客戶上了第一個HA系統，當時數據庫是在WINDOWS NT上的，HA軟件用的就是著名的ROSE HA。自從Oracle RAC比較成熟后，數據庫高可用基本上就是RAC的天下了。

2000年左右，Oracle推出了MAA高可用架構，Oracle RAC+DATAGUARD的組合構建了十分優秀的高可用體系。這些年O記的高可用方案越來越豐富，0數據丟失備份一體機，基于MAA+OGG的白金MAA架構等，層出不窮。很多商業銀行也借助Oracle MAA構建出新的兩地三中心架構，這個架構比起大型機中型機時代來，既安全又便宜。

進入國產數據庫時代，技術堆棧發生了巨大的變化，不過高可用這個問題在國產數據庫時代并不會弱化。我們依然需要為國產數據庫構建類似Oracle HA/RAC/ADG/OGG等高可用架構以保障業務系統的安全運行。

國產數據庫大多數已經模仿Oracle構建了自己的完整的高可用架構，以達夢數據庫為例，就有一整套對標Oracle的技術棧來確保業務系統的高可用。    

圖片

如上圖，DM DataWatch是對標Oracle DataGuard的基于Redo復制的高可用解決方案，也是目前在達夢數據庫應用中使用最為廣泛的方案。    

圖片

上圖是目前在達夢用戶中最為常用的一種基于DataWatch的高可用部署架構。A機房的主備庫采用同步復制的模式，當主庫故障時可以快速接管業務。B機房的備庫可以根據網絡條件選擇同步或者異步復制模式，作為災備解決方案。    

圖片

而對于SLA要求更加嚴格的核心業務系統，達夢也可以利用其對標Oracle RAC的DM DSC集群+DataWatch的方案構建業務連續性更加優秀的高可用方案。

圖片

對于分布式數據庫而言，其高可用解決方案則更為豐富，不過其建設成本也更高。我們以OceanBase為例，面對金融機構的業務連續性要求，在一套OceanBase分布式數據庫集群中構建三地五中心的高可用架構。選擇兩個近地域，網絡延時較低的城市的四個機房構建出四個業務ZONE，每個ZONE可以承擔1/4的業務負載。而在較遠地域的城市3建設第五個ZONE，如果你使用了4.X版本，第五個機房可以只放置日志，而不需要數據文件，從而節約成本。當然為了確保業務的性能，近地域機房之間的網絡延時越低越好，最好能夠低于2毫秒。    

圖片

GaussDB也有類似的解決方案，上面是一個同城三中心雙活的解決方案，AZ1/AZ2的8臺服務器承擔核心業務，可以通過全局負載均衡實現雙活，AZ3只參與仲裁，因此在Server9上只部署了一個ETCD備實例。

圖片

經常有朋友問我，分布式數據庫需要不需要類似Oracle ADG的架構呢？我的答案是根據自己的資金情況、機房情況、網絡情況可以選擇不同的高可用解決方案。對于不能出現嚴重故障的超關鍵的業務系統，怎么做高可用保障都是不為過的。上圖是一個運營商的 CRM系統，主備集群分別位于兩個城市。其中城市A的三個ZONE分別凡不在IDC1和IDC2兩個數據中心里，構建了同城高可用環境。同時通過日志將數據復制到異地的另外一個OB集群里，平時這個集群承擔一部分讀的業務。這個模式是不是和Oracle RAC+ADG十分類似？    

圖片

GaussDB在一些金融行業用戶側主推了一個基于Dorado雙集群的高可用解決方案。采用的是GaussDB集中式部署模式，主庫的Redo Log會寫一份Shared Redo Log，這個Redo Log被Dorado同步復制到遠程的另外一個Dorado集中式存儲中，因此備AZ的GaussDB Standby數據庫是零數據丟失的。這個和當年我們在Oracle ADG上實現零數據丟失的方案是一模一樣的。