2022年1月15日，湯加火山突然劇烈噴發，火山噴發不僅使得湯加全境面臨海嘯、暴雨、洪水和強風的威脅，遮天蔽日的火山灰還嚴重阻礙了通信，使得湯加瞬間陷入了全境“失聯”的狀態，與外部世界的聯系幾乎完全中斷。

在如此巨大的自然災害的面前，傳統的數據庫高可用架構顯得不堪一擊——部署在湯加本地的機房不可避免地遭遇了斷電，無法對外提供服務;關鍵的業務數據丟失，產生了不可估量的損失。

地球的雷霆怒火面前，人類總是顯得無比渺小，面對災害無力回天。如何居安思危，通過有效的災備方案，快速恢復生產、業務和服務，降低區域性災難對企業數據的破壞，減少負面沖擊，這是無數企業亟待解決的問題。

“兩地三中心”解決方案就是為應對此類大范圍自然災害而提出的。“兩地三中心”中的兩地是指同城、異地;三中心是指生產中心、同城災備中心、異地災備中心。當單個地域的業務無法幸存時，可以采用同城雙中心加異地災備的“兩地三中心”容災備份解決方案，來應對大范圍自然災害導致的業務中斷和數據丟失。

金倉KingbaseES兩地三中心高可用災備解決方案可以完美解決各種場景下的災備切換問題。下面，讓我們來看看金倉KingbaseES的“兩地三中心”實現方案。

金倉KES數據庫的兩地三中心架構

金倉KingbaseES集群支持的兩地三中心容災系統屬于數據級的容災，提供數據庫軟件的兩地三中心解決方案，易用、易維護、可靠性高;并且用戶可以在金倉KingbaseES的兩地三中心方案上對應用和業務進行改造，構造應用級或業務級容災系統。

定義：

兩地三中心：一種業務連續性容災方案。三數據中心并存的特性，能在任意兩個數據中心受損的情況下保障核心業務的連續，大大提高容災方案的可用性。

生產中心：對外提供服務。

同城災備中心：通常在離生產中心幾十公里的距離建立同城災備中心，應用可在不丟失數據的情況下切換到同城災備中心運行，是兩地三中心容災方案的第一級容災保護。

異地災備中心：通常在離生產中心幾百或者上千公里的地方建立異地災備中心，應對區域性重大災難，實現異步復制災備，是兩地三中心容災方案的第二級容災保護。

SYNC：節點間同/異步關系，SYNC表示同步模式，數據會實時地同步傳輸到SYNC指向的節點。

ASYNC：節點間同/異步關系，ASYNC表示異步模式，數據會非實時地同步傳輸到ASYNC指向的節點，數據可能有一定的滯后性。

RTO(Recovery Time Objective)：從災難發生到整個系統恢復正常所需要的最大時長。

RPO(Recovery Point Objective)：最多可能丟失數據的時長。

●能力

當前，人大金倉KingbaseES"兩地三中心"提供如下功能：

1.數據同步，在多個副本之間進行數據同步，并基于同城短距離和異地遠距離的不同場景提供最優的數據同步方案;

2.熱備，備庫可讀，分擔業務壓力，識別讀寫事務并進行分發，降低單個數據副本的業務壓力，提高整套系統的處理能力;

3.故障切換與故障恢復能力，保證7*24小時提供數據服務，各種軟硬件故障下能夠提供安全可靠的數據服務，最大程度提供數據可靠性和服務持續性;

4.獨立備份，生產數據最后的保障，即使整套業務、數據庫系統都無法恢復，還有最后的獨立備份數據作為最終數據安全保障手段。

●方案優勢

相比跨中心的同城容災和跨地域的異地容災，兩地三中心容災方案結合兩者的優勢，可以同時應對中心級別故障和地域級別災難。

對于中心級別故障，容災切換時保證數據庫數據一致性。

對于地域級別災難，該方案可將業務恢復至異地災備數據，盡可能保全業務數據不丟失。

金倉KES兩地三中心集群災難恢復演練

●演練目標

通過實戰演練，檢驗金倉KingbaseES兩地三中心集群應對各種故障場景的能力：

A、是否支持自動故障切換和資源恢復

B、驗證業務恢復的時長

C、檢驗數據同步延遲情況

●演練環境

此次金倉KingbaseES兩地三中心集群災難恢復演練采用5個數據庫節點的模式，將生產中心、同城災備中心放置于成都相隔30km機房，異地災備中心放置于北京機房(成都至北京的直線距離約為1500km，絕大多數用戶的災備系統設計的災備距離不會超過此值，最大限度地覆蓋了客戶的災備場景)。服務器節點信息如下圖：

●演練內容 | 生產中心整體故障

模擬生產中心主庫和備庫全部發生故障的場景：例如處于成都地域的生產中心機房遭到破壞，整體斷電或者異常病毒造成設備癱瘓。

檢驗金倉KingbaseES兩地三中心集群對上述故障的處理能力、故障處理能力邊界及故障對業務的影響時長。

●自動故障切換

應用業務訪問的生產中心故障，同城災備中心經過集群多節點間心跳判斷生產中心已不可訪問。同城災備中心迅速自動故障切換，提升本中心繼續為應用提供服務，僅需秒級的業務恢復時長!

該階段的容災RPO等于0，RTO在幾秒-幾十秒內(可配置)。

●自動恢復加入集群

當生產中心整體發生故障時，切換后主庫轉移到同城災備中心。之后，位于同城災備中心的主庫，將自動對生產中心的故障數據庫進行恢復(例如此時生產中心已恢復供電或解決了設備癱瘓問題)。

先自動恢復node1，作為同步備庫恢復。再自動恢復node2，作為異步備庫恢復。在業務恢復期間，同城災備中心始終對外提供服務，恢復過程對用戶無感，RTO/RPO=0!

同時，當生產中心整體恢復后，又可作為當前同城災備中心的同城容災節點，提供與之相應的故障處理能力，業務又回到開始的同城雙中心均可訪問的場景。

●演練內容 | 生產中心和同城災備中心全部故障

模擬生產中心和同城災備中心全部故障的場景：例如處于成都的生產中心和同城災備中心因不可抗力的因素整體遭到破壞。

該階段的容災RPO取值為 0 ~ 數秒/數分鐘。取決于業務帶寬規劃值和業務高峰/低峰區。RTO一般建議用戶手動切換執行，自動切換在數分鐘內。

位于北京的異地災備中心可手動/自動切換至對外提供服務的狀態，作為數據系統最后的保障。此場景一般從應用層面系統性地規劃應用/業務系統和數據系統整體的計劃遷移。金倉為此類災難級恢復也提供了基礎保障。

●演練內容 | 實測生產中心、同城災備中心、異地災備中心數據差異

通過實戰演練，查看生產中心、同城災備中心、異地災備中心數據同步延遲情況，直觀了解實際地域距離、網絡帶寬、網絡延遲等對數據同步的影響。客戶可以根據自己的業務場景來決定容災環境的設置標準(網絡帶寬、容災距離等)。

本次測試主要關注數據差異值的范圍。

測試1：kbbench灌1000萬數據

./kbbench -Usystem -p10001 -i test -s100-s 100比例因子，會在內置的一個10w行數據表放大100倍，將在kbbench_accounts表中創建10,000,000行。共計數據量：

Total data size: 1554 MB產生的數據庫日志量：

test=# selectsys_size_pretty(sys_wal_lsn_diff('0/80008A8','0/56888B20'));sys_size_pretty-----------------1257 MB

(1 行記錄)

比較運行過程中生產中心與同城災備中心的同步備機日志差異：

●日志無差異;

●數據庫的同步機制在業務層面上是保證完全一致。

select application_name,sys_wal_lsn_diff(sys_current_wal_flush_lsn(),flush_lsn)/1024/1024 as MB from sys_stat_replication;application_name | mb------------------------------+------------------------node2 | 0.00000000000000000000node3 | 0.00000000000000000000

(2 行記錄)

比較運行過程中同城災備中心與異地災備中心的異步備庫日志差異：

●異步備庫處于同城，級聯(串聯)的特性極大緩解了生產中心到同城災備中心的網絡壓力，(在CPU、IO等未達到瓶頸時)即使是異步模式，也可以實時同步級聯節點完成數據同步。

●異地災備中心的數據庫，日志差異較大，最高峰達984M左右的差異(差異值主要取決于距離和帶寬、網絡延遲。因此，需提前規劃好異地的帶寬配置情況，以滿足累積日志平均每天近飽和的傳輸完。金倉可利用日志壓縮功能，為用戶更多地節省昂貴的異地專用帶寬)。

test=# selectapplication_name,sys_wal_lsn_diff(sys_last_wal_receive_lsn(),flush_lsn)/1024/1024as MB from sys_stat_replication;application_name |mb------------------------------+------------------------node4 | 0.00000000000000000000node5 |984.2698364257812500test=# select application_name,sys_wal_lsn_diff(sys_last_wal_receive_lsn(),flush_lsn)/1024/1024as MB from sys_stat_replication;application_name | mb------------------------------+------------------------node4 | 0.00000000000000000000node5 |754.11923456456578460(2 rows)

ps：測試過程中，異地帶寬已占滿20MB/s，證明高峰期數據的差異帶寬占了很大的決定性作用。

測試2：模擬500客戶端并發測試，運行5min

./kbbench -Usystem -p10001 -r -j 64 -c 500 -T 300 test

運行結束后產生日志

：test=# select sys_size_pretty(sys_wal_lsn_diff('0/9C040C80','0/BC3CE7A0'));sys_size_pretty-----------------516 MB

(1 行記錄)

比較運行過程中生產中心與同城災備中心的同步備機日志差異，日志無差異。

test=# select application_name,sys_wal_lsn_diff(sys_current_wal_flush_lsn(),flush_lsn)/1024/1024 as MB from sys_stat_replication;

application_name | mb

------------------------------+------------------------

node1 | 0.00000000000000000000

node3 | 0.00000000000000000000

(2 rows)

比較運行過程同城災備中心異步備庫與異地災備中心異步備庫日志差異，異地容災節點趨近于0，可以看到在異地帶寬滿足正常業務流量時，波動非常穩定。

test=# select application_name,sys_wal_lsn_diff(sys_last_wal_receive_lsn(),flush_lsn)/1024/1024 as MB from sys_stat_replication;

application_name | mb

------------------------------+------------------------

node4 | 0.00000000000000000000

node5 |0.8233871459960938

(2 rows)

小結

在實際演練過程中，還有其他幾類場景，金倉KingbaseES兩地三中心集群故障處理結果總結如下：

●生產中心和同城災備中心可以保證數據無丟失的RPO=0、RTO=秒級的高可用容災方案。在各類場景的演練均能做好數據不丟，服務不斷，無須人工干預的企業級處理標準(對應信息安全技術信息系統災難恢復規劃6級)。

●異地災備中心數據差異有一定的波動。差異值主要取決于距離和帶寬、網絡延遲，金倉會提前幫助客戶規劃好異地的帶寬配置情況，以滿足當前業務系統評估日志每天的生成量，制定合理的帶寬值。同時利用日志壓縮功能，可以壓縮日志在50-70%以上，可為用戶節省昂貴的異地專用帶寬。在合理的滿足業務流量需求上，RPO可以達到秒級。RTO推薦用戶手動執行，自動切換異地災備默認RTO在數分鐘內完成。

應用案例

當前，金倉KingbaseES“兩地三中心”方案已在x中心核心業務系統中成功應用，為關鍵政務數據的安全保駕護航。

系統于2020年底上線并穩定運行后，該中心技術負責人致電金倉，充分肯定金倉方案、產品及服務團隊的專業性和先進性，對金倉在項目中的勤奮務實與專業精神予以贊揚并表示感謝。

結語

隨著互聯網的不斷發展和電子政務建設步伐的邁進，各行各業不斷加緊開展線上業務，越來越多的用戶核心業務都要求二十四小時不斷網，持續運行，對數據安全提出了更高的要求。

但是，地震、海嘯、龍卷風、火山噴發、泥石流、山體滑坡，以及氣候變化引發的干旱、洪水.....如同達摩克里斯之劍一般懸在我們頭頂，隨時威脅著數據安全，影響著人類文明的進程。身處地球，沒有誰能置身事外。誰都無法預測這些自然災難將會何時降臨，切斷服務、摧毀業務核心數據。這就需要我們具備應對各種災難、故障場景的能力，而金倉KingbaseES兩地三中心集群將會是您最好的選擇。

完善的災備方案、智能的故障自動恢復和資源轉移、瞬時的業務恢復時長......金倉KingbaseES兩地三中心集群，與您一起應對各種災難場景，帶您避免自然災害對業務的毀滅性打擊!