高可用架構(gòu)是關(guān)鍵數(shù)據(jù)庫(kù)應(yīng)用必須考慮的，昨天我的文章里也說過，數(shù)據(jù)庫(kù)出故障不可怕，只要不出現(xiàn)業(yè)務(wù)受到嚴(yán)重影響的事故就可以了。而確保業(yè)務(wù)不出事故的方案中必然少不了數(shù)據(jù)庫(kù)的高可用架構(gòu)。

早期數(shù)據(jù)庫(kù)是沒有高可用架構(gòu)的，數(shù)據(jù)庫(kù)就成了著名的單點(diǎn)故障點(diǎn)。后來引入了HA，Oracle也祭出了OPS/RAC這個(gè)大殺器。98年的時(shí)候，我給客戶上了第一個(gè)HA系統(tǒng)，當(dāng)時(shí)數(shù)據(jù)庫(kù)是在WINDOWS NT上的，HA軟件用的就是著名的ROSE HA。自從Oracle RAC比較成熟后，數(shù)據(jù)庫(kù)高可用基本上就是RAC的天下了。

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

進(jìn)入國(guó)產(chǎn)數(shù)據(jù)庫(kù)時(shí)代，技術(shù)堆棧發(fā)生了巨大的變化，不過高可用這個(gè)問題在國(guó)產(chǎn)數(shù)據(jù)庫(kù)時(shí)代并不會(huì)弱化。我們依然需要為國(guó)產(chǎn)數(shù)據(jù)庫(kù)構(gòu)建類似Oracle HA/RAC/ADG/OGG等高可用架構(gòu)以保障業(yè)務(wù)系統(tǒng)的安全運(yùn)行。

國(guó)產(chǎn)數(shù)據(jù)庫(kù)大多數(shù)已經(jīng)模仿Oracle構(gòu)建了自己的完整的高可用架構(gòu)，以達(dá)夢(mèng)數(shù)據(jù)庫(kù)為例，就有一整套對(duì)標(biāo)Oracle的技術(shù)棧來確保業(yè)務(wù)系統(tǒng)的高可用。    

圖片

如上圖，DM DataWatch是對(duì)標(biāo)Oracle DataGuard的基于Redo復(fù)制的高可用解決方案，也是目前在達(dá)夢(mèng)數(shù)據(jù)庫(kù)應(yīng)用中使用最為廣泛的方案。    

圖片

上圖是目前在達(dá)夢(mèng)用戶中最為常用的一種基于DataWatch的高可用部署架構(gòu)。A機(jī)房的主備庫(kù)采用同步復(fù)制的模式，當(dāng)主庫(kù)故障時(shí)可以快速接管業(yè)務(wù)。B機(jī)房的備庫(kù)可以根據(jù)網(wǎng)絡(luò)條件選擇同步或者異步復(fù)制模式，作為災(zāi)備解決方案。    

圖片

而對(duì)于SLA要求更加嚴(yán)格的核心業(yè)務(wù)系統(tǒng)，達(dá)夢(mèng)也可以利用其對(duì)標(biāo)Oracle RAC的DM DSC集群+DataWatch的方案構(gòu)建業(yè)務(wù)連續(xù)性更加優(yōu)秀的高可用方案。

圖片

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

圖片

GaussDB也有類似的解決方案，上面是一個(gè)同城三中心雙活的解決方案，AZ1/AZ2的8臺(tái)服務(wù)器承擔(dān)核心業(yè)務(wù)，可以通過全局負(fù)載均衡實(shí)現(xiàn)雙活，AZ3只參與仲裁，因此在Server9上只部署了一個(gè)ETCD備實(shí)例。

圖片

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

圖片

GaussDB在一些金融行業(yè)用戶側(cè)主推了一個(gè)基于Dorado雙集群的高可用解決方案。采用的是GaussDB集中式部署模式，主庫(kù)的Redo Log會(huì)寫一份Shared Redo Log，這個(gè)Redo Log被Dorado同步復(fù)制到遠(yuǎn)程的另外一個(gè)Dorado集中式存儲(chǔ)中，因此備AZ的GaussDB Standby數(shù)據(jù)庫(kù)是零數(shù)據(jù)丟失的。這個(gè)和當(dāng)年我們?cè)贠racle ADG上實(shí)現(xiàn)零數(shù)據(jù)丟失的方案是一模一樣的。