摘要：本文主要是探討OLAP關係型資料庫框架的資料倉庫平臺如何設計雙集群系統，即增強系統高可用的保障水準，然後討論一下GaussDB(DWS)的容災應該如何設計。

當前社會、企業運行當中，大資料分析、資料倉庫平臺已逐漸成為生產、生活的重要地位，不再是一個附屬的可有可無的分析系統，外部監控要求、企業內部服務，湧現大批要求7*24小時線上的應用，逐步出現不同等級要求的雙集群系統。

資料倉庫主流資料庫平臺均已存在多重高可靠保障措施設計，如硬碟冗餘的raid設計、資料表冗餘、節點備用冗餘、機櫃備用資料交叉等，以及加上服務程序高可用冗餘設計，其最大化程度滿足資料倉庫服務持續線上。

但現實場景，如資料庫軟體缺陷、定期加固補丁、產品迭代、硬體升級這些產品現實因素，以及來自機房、資料中心、地域、網路的外部災難故障因素，均在降低資料倉庫可用性服務水平。

鑑於資料倉庫存在大量資料吞吐，針對不同資料庫、不同可用性要求，若需要設計雙叢集冗餘設計，可選技術手段分別有資料同步模式、雙ETL模式、雙活模式，具體探討如下：

1.資料同步模式

a)架構

由於資料庫IO能力有限、且兩個資料庫間頻寬有限，除了首次全量同步之後，後續通常考慮增量同步技術，即如何準確、高效獲取“變化資料”，一般存在日誌同步技術、備份增量同步技術、邏輯資料同步；

b)日誌同步技術

日誌同步技術，有業內最著名Oracle Golden Gate，大部分廠家也有自己的實現方式，像Teradata近年來推出Unity CDM（變化資料廣播）技術，而我司GaussDB for DWS可採用xlog及page進行變化資料同步。

優勢：直接同步變化資料增量，資料量少，要求頻寬低，但目前市面技術大都只適合資料每日變化量較少的資料倉庫環境；

劣勢：現實的技術門檻高，應對各類異常場景適應能力差，對主資料庫侵入效能要求高，一旦主庫繁忙，同步時效低；面對全刪全插等變化資料量大場景，同步吃力；

c)備份增量同步技術

主要利用各資料庫平臺備份恢復能力，進行資料增、全量備份、恢復；通常源庫備份資料壓縮之後，經網路傳輸後，解壓恢復到目標庫；對應GaussDB for DWS可採用roach備份恢復工具實現；

優勢：利用同一技術實現增、全量資料同步，邏輯清晰，各場景容錯能力強；

劣勢：要求資料庫支援增備能力，且往往鎖等待嚴重；

d)邏輯資料同步

該項主要涉及較高的業務侵入性，即充分獲取ETL排程資料流元資料，對應資料庫當日資料穩定之後，發起資料表匯出-匯入操作，針對資料表加工特性，選擇增全量同步規則，進行資料準實時同步。

優勢：較上述同步技術，可以實現多樣選擇性同步，同步過程由實施專案本身控制，做到表級資料同步，不需要全系統同步，即可實現部分業務雙叢集；

劣勢：客戶化同步邏輯，操作前置依賴多，實施投入人力多，較難推廣；

2.雙ETL模式

a)架構

即採用兩套獨立排程平臺進行資料加工，抽取同一個資料來源（往往是落地穩定的資料交換平臺），採用同一套ETL程式碼依賴邏輯排程，各自生成目標資料，往往批量過程中，採取主庫對外持續服務，待主備庫資料準實時或批後校驗一致後，再開放備庫對外服務。

若雙叢集資料發生不一致場景，主要以主庫資料為準，覆蓋備庫。該同步過程，需要使用到“資料同步模式”相關同步技術。

b)參照落地架構

c)載入源資料考慮

為保證兩套ETL排程載入資料來源一致及資料複用，往往要求搭建一個數據交換平臺。因為至少存在一個檔案被兩套排程讀取，要求資料交換平臺兩倍過往吞吐能力；且禁止載入的資料檔案被二次覆蓋，導致兩套系統載入不一致；

d)排程依賴順序考慮

由於ETL作業排程關係沒有配置完備，即存在A作業使用B作業的資料，但不配置依賴關係（絕大部分的情況是A作業可容忍B資料的時效，是否最新資料均可以使用，故為時效，業務上不配置依賴關係；當然也存在物理時間上，通常B遠遠早於A執行），導致兩套系統A作業生成資料不一致。

該場景下，在一套排程平臺無法發現此問題，但存在兩套系統的校驗比對，即發現數據不一致；

該問題建議使用者補全依賴關係，確認執行順序一致性；

當然若希望靈活使用依賴關係，則需二次開發，控制兩套排程當日時序一致性；

e) ETL程式碼伺服器考慮

為了避免兩套ETL排程程式碼維護不一致，需考慮統一維護渠道，包含不限於同一個程式碼儲存源、版本伺服器，以及程式碼變更時機

f)存在不確定值的SQL函式返回

ETL程式碼中往往存在sample、random、row_number排序這種同一份資料產生不同結果集的函式，造成兩套系統資料不一致；

該問題建議使用者使用替代函式、明確取值、唯一排序，確保最終資料一致性；

同時，該設計邏輯正確情況下，哪份資料均可被業務採信，若該資料對下游影響少，可每日批後從主庫同步備庫，拉平資料；

g)報錯修數邏輯考慮

其中一套系統的資料發生報錯、修數行為，會涉及到另一套系統的維護行為；

可選作法是保留操作邏輯，待另一套系統發生報錯時重複執行一次；

其它交給資料質量校驗（DQC）、資料校驗去複查；

h)干預重跑修數邏輯考慮

若批後重跑，兩套系統重跑邏輯一致，涉及重複勞動（或支撐平臺優化），相對簡單；

但涉及批量過程中發現部分資料需要重跑，由於兩套排程進度不一致，會導致

i)資料校驗

i.校驗時機

批後校驗，邏輯清晰，對排程依賴少，即根據整體排程進度，做到分層、分庫或整體資料校驗；

準實時校驗，即侵入排程環節，在每個作業完成時，均發起日誌解析，提取每個SQL影響記錄數，若相應作業SQL存在影響記錄數不一致場景，即中止較晚完成的排程平臺排程後續作業；

ii.校驗手段

增全量校驗，即針對不同加工邏輯的資料表，區分增、全量資料值，以最小代價覆蓋所有業務表

iii.校驗方法

通常作法有記錄數、彙總值、checksum校驗；

彙總值校驗，通過是數值型欄位直接sum、字元型計算字元長度的sum、時間型別則轉換成數值相加的比對；

Checksum校驗，針對全表或部分欄位，進行md5或hash運算，完成兩套系統一致性比對；

對於關係型資料庫，校驗開銷代價逐步遞增（記錄數 < 彙總值 < checksum校驗）；往往是結合增量校驗、結合重要指標，區分維度校驗，日常增量邏輯校驗，定期全量校驗，在校驗資料一致性和系統性能之間取得平衡點。

j)優化考量

i.校驗改進

即嵌入排程平臺，提取ETL程式碼執行日誌，通過執行SQL影響的記錄值，實時進行兩套系統完成作業日誌比對，發現記錄值影響，立即停止備庫排程，採用人工或自動方式修復資料，繼續後續批量。

該作法最大好處是，即時發現數據異常，避免問題放大，保障備庫更高可用性；

ii.引入統一維護平臺

即減少人為雙系統維護操作，程式碼變更平臺化，修數邏輯平臺化，由平臺分別下發兩套排程平臺、兩套資料庫。

3.雙活模式

以下基於Teradata Unity產品理念的延伸構想

a)架構

b)雙活功能點

i.訪問路由能力

客戶端直接將中介軟體作為資料庫登陸，保持原來登陸邏輯不變；

中介軟體根據登陸使用者及附加引數實現拒絕登陸、雙系統登陸、或單系統登陸，實現寫登陸、讀登陸，實現受控方式登陸、或非受控方式登陸；即實現受控和非受控方式的系統讀寫；

同時兼顧考慮異常路由選擇或同步路由選擇，滿足最大化異常執行及少部分同步需求場景；

ii. SQL分發能力

經中介軟體傳送的SQL指令，正常傳送到相應資料庫，並接受資料庫響應資訊；

iii.批量匯入、匯出能力

針對資料大批量的匯入，需要考慮採用更加高效的載入協議進行資料載入，並考慮經中介軟體複製資料塊，非同步分發兩個資料庫；

資料匯出，需要考慮高效資料匯出協議，從其中一套資料庫正確匯出資料；

iv.更新類SQL校驗能力

Delete、Update、Insert、Merge等更新類DML SQL進行SQL影響記錄數校驗；

DDL/DCL執行返回碼驗證一致性能力；

v.物件註冊功能

通過路由及建立物件的DDL語句，實現物件動態註冊；

通過命令列指令實現物件註冊；

適當增加物件索引、約束索引的註冊資訊，用於擴充套件細粒度物件鎖能力，提高資料倉庫ETL SQL併發能力；

*資料倉庫環境下，只需要考慮到表級雙活的能力，不建議實施欄位級、記錄級雙活；

vi.物件鎖能力

根據SQL指令給相應物件動態加鎖、釋放鎖；

同時根據資料庫自帶的鎖特徵，至少區分讀、寫鎖控制，以及部分資料庫的髒讀功能鎖；

vii.物件狀態控制能力

進行管理的多套資料庫線上狀態控制；

進行物件狀態控制功能，包含不限於線上、離線、只讀、只寫、主動中斷快取中、被動中斷快取中、不可用等狀態；

viii. 快取能力

進行SQL指令流快取能力，以及快取恢復執行的能力；

進行SQL與載入資料結合快取、以及快取恢復執行的能力；

ix. SQL異常控制能力

考慮使用者體驗，始終由返回響應正確的SQL指令返回客戶端；

兩個資料庫返回均成功，但返回的影響記錄數不一致，則響應慢的資料庫對應SQL及涉及物件被設定成不可用狀態；

若兩套資料庫其中一套執行成功，另一套執行失敗，則執行失敗的資料庫SQL和涉及物件被設定為被動中斷快取中，同時快取SQL，定時重試SQL；

若兩套資料庫返回均報錯，才通知客戶端報錯；

若SQL涉及物件已處理非線上狀態，則新提交的SQL被快取，新提交SQL相應物件被設定為被動中斷快取中。

針對中介軟體和資料庫之間，存在資料庫已執行完、但中介軟體未收到訊號場景，需考慮閃環該場景（如增加事務鎖等）；

c) Teradata Unity參照落地架構

ü 主要通過Unity實現多叢集SQL、資料分發與管理；

ü Data Mover實現叢集間資料同步；

ü Eocsystem Manager實現資料批後自動校驗及不一致重同步事件觸發；

ü Viewpoint實現系統平臺透檢視展現與維護，並對接使用者告警平臺；

d)中介軟體高可用考慮

由於引入了中介軟體（前置）服務，即該服務的穩定、可靠對雙活模式至關重要。

資料庫單套系統本身已經具備極高的可用性，引入中介軟體後，由於所有資料庫訪問行為均通過該中介軟體，中介軟體任何異常均同時影響兩套資料庫訪問能力。

除了中介軟體本身所有相關服務需要滿足高可用之外，還需考慮極端場景下bypass能力，此項能力在於極端異常條件下，可以保障系統持續服務的能力。

高可用場景中，存在控制節點腦裂與自動升主場景，需借鑑仲裁機制減少腦殘裂發生；

e) 資料重同步考慮

即利用“資料同步模式”相關同步技術，實現兩套資料庫資料重同步能力；

f)不確定值的SQL函式考慮

最佳方案，是採用“資料同步模式”的資料日誌重同步技術，直接將第一套資料庫SQL執行結果的日誌資訊同步到第二套資料庫中，消除返回結果不一致；

部分簡單的系統時間函式，直接通過中介軟體改寫，保障SQL執行結果一致性；

另外，則通過SQL改寫，保證row_number函式進行主鍵或全欄位排序，保證SQL執行結果一致性；

g)異常會話重放能力

針對異常會話過程的SQL，可能需要從會話建立後，視覺化選擇，倒回前幾個SQL重新執行，並指定過程SQL是否參與結果集校驗，以及SQL回放結束的確認動作，讓異常場景處理手段更加豐富。

4.適用場景

a) “資料同步模式” – 日誌同步技術

適用資料變化量小、資料傳輸壓力小的資料場景，通常只適用於小型資料倉庫平臺；

對於規模小的平臺，RPO、RTO可以接近0；

b) “資料同步模式” – 備份增量同步技術

適合大資料量同步場景，實現方式容易被使用者理解；

往往需要資料庫備份工具具備增量備份恢復能力；同時考驗備份工具消除相關硬體限制條件，讓該技術方案更加靈活；

雙叢集的初始化同步往往採用全備全恢的邏輯實現，可以最大化、最快拉平存量資料；

對於規模大的平臺，RPO往往需要小時級別，RTO最好水準也在分鐘、10分鐘以上；同時主叢集需要保障一定資源量供資料同步使用，對主叢集開銷大；

c) “資料同步模式” – 邏輯資料同步技術

適用靈活同步場景，往往資料同步量不會太大，或同步時間可容忍場景；

此場景往往適合於使用者對其資料倉庫ETL過程元資料資訊清晰、完整，依賴客戶開發能力，相關同步資料存在清晰ETL演算法，結合排程作業執行進度，動態發起相關資料表增、全量同步；

對於中等規模的平臺，RPO可以做到分鐘、半小時，RTO可以維持在分鐘級；

d) “雙ETL模式”

需要兩套ETL排程環境，整體成本翻倍，但排程邏輯清晰、易於理解和維護；

較容易匹配不同規模的資料倉庫平臺採納；

較難實現資料實時比對，以及資料發生不一致之後的控制邏輯（若需要實現，對於排程邏輯侵入性大）；

ETL排程批量中途，較難實現兩套排程鏈路協調重跑；

同時資料不一致，依賴於”資料同步模式”技術輔助實施；

由於主備排程進行不一致，無法做到主備統一檢視展現；

若雙叢集硬體相當，RPO、RTO均可以維持在分鐘級別；

e) “雙活模式”

需要獨立中介軟體、且嚴重依賴資料庫自身廠商，中介軟體實現難度大；

中介軟體的高可用（穩定性）成為它落地的最大障礙；

“雙ETL模式”的升級版，能適應各類資料倉庫雙叢集場景；

絕大部分場景下，RPO、RTO均可以接近0，特別是雙活同時線上能力，不存在雙叢集的主備切換，RTO可以做到0；同時存在統一檢視，不會因為其中一個叢集故障，造成前後同一個查詢返回結果不一致場景；

5.總結比對

接下來，我們展開討論一下GaussDB(DWS)的容災應該如何設計。

對於方案探討中涉及到幾種形態，從數倉核心的角度去分析一下各個方案的問題：

• 日誌同步技術：

1. 列存資料不記日誌無法通過日誌來同步
2. 支援列存xlog後會導致匯入效能劣化，xlog資料量大，同時會影響日誌同步效率

• 備份增量同步技術：

1. 無法達到 RPO = 0
2. 備叢集只能讀，無法支援寫操作

• 邏輯資料同步技術：

1. 列存資料需要支援邏輯解碼，需要從列存XLog的方向進行演進
2. 分散式事務，DDL等處理難度較大

• 備份/恢復

1. 不能馬上提供服務，RTO時間較長
2. 需要較大空間儲存備份集

GaussDB(DWS) 當前在備份增量同步和備份/恢復兩個方向進行演進，他們都是基於備份/恢復工具Roach

(詳情參見Roach備份恢復GaussDB(DWS))

• 備份/恢復

備份/恢復的原理圖如下，在各個結點將例項備份到相應的介質上，並從介質上恢復到新叢集或老叢集中。詳細的功能不在此處展開描述，大家可以參考(詳情參見Roach備份恢復GaussDB(DWS)) 來了解細節。

對於實現容災要求，需要解決的問題大體分三類：

• 快速的備份恢復

高效能備份、恢復操作保證在較短的時間內將資料遷移到另一個叢集，對於RPO/RTO要求不大的系統來說實現和使用非常簡單。

• 備份恢復在叢集可用的情況下即可進行，不受單點故障的影響

備份恢復在叢集可用的情況下就可以進行，叢集只需要保證有可用副本就可以持續的進行備份，並且可以正常恢復。

• 備份集的可靠性

備份集需要儲存在可靠的儲存上，類似 OBS/NBU, 由於磁碟故障率相對比較高，類似備份集儲存在磁碟上是非可靠的方案。

• 雙叢集備份增量同步技術

當前GaussDB(DWS)使用在備份/恢復的雙叢集架構來實現容災，將生產叢集的資料使用增量的方式同步到容災的叢集。

在這種架構下需要解決如下問題：

1.減少RPO

備份恢復無法達到與流式的同步方式的RPO， 做不到RPO=0的程度。

2.備叢集的可用性問題

• 備叢集支援持續讀/寫

備叢集是物理恢復的方式，無法支援寫的操作的；但是在恢復過程中是可以支援持續讀的，當前在恢復過程中需要停集群后將備份集中檔案覆蓋。

• 備叢集叢集恢復失敗可回退到一致性狀態

在恢復過程中會出結點故障，備份集損壞等等問題，會造成當前的恢復過程無法執行過去，此時需要回退到恢復前的狀態，保證備叢集的可用性。

• 備叢集恢復不受單點故障影響

對於備叢集來說，也會出現各種單點故障的情況，例項故障，結點故障，CN剔除等情況下，仍然可以把叢集恢復成可用的狀態。

• 備叢集支援備份

備叢集可以支援備份，用於擴充套件一些其它功能，實現類似多AZ，異地的容災。

3.備份集管理

• 備份集生命週期管理

容災是實現資料同步的功能，並非一個備份恢復場景，並不需要儲存大量備份集以及週期的去做全量備份，因此需要有一個機制實現備份集及時清理，保證佔用資源可按。

• 備份集的可靠性

在容災過程中，同樣考慮備份集的可靠性，防止備份集損壞情況，可以通過可靠的介質來儲存備份集，又能保證可靠的讀寫效能。

• 持續增量資料同步

保持持續的增量備份，類似升級前後，擴容前後，都要保持增量備份來保證同步的效能。這裡隱含著一個顯而易見的原因，如果全量備份的話，備份時間長，並且恢復進會將叢集清空，此時容災叢集不可用，這個嚴重影響可用性。可以說避免全量備份是基於Roach的雙叢集容災一個重要工作。

4. 雙叢集切換及Failover

• 快速切換

雙叢集的應用場景中，類似滾動升級，故障演練，此時需要切換兩個叢集，切換時要保證快速將兩邊資料拉平，儘快提供服務並保證可用性。

• Failover及之後的加回操作

由於RPO != 0，所以在生產叢集無法提供服務時,容災叢集在Failover操作後會提供讀寫服務，此時會有一部分資料丟失，並在兩個叢集的資料產生了“分叉”，那麼在生產叢集恢復後，加回之後中要將“分叉”的資料進行回退，以保證兩邊資料一致。

5. 異構的支援

此處異構是指邏輯結構DN數量一致，而CN數、結點數可以不相同的情況，眾所周知是由於當前方案是物理備份方式，因此如果DN數量發生變化，無法從物理層進行重分佈操作。

以上說明的幾點都是基於可靠性的角度來分析，還有一個重要的因素是基於數倉的資料量和叢集規模，不論備份/恢復方案還是在此基礎上的雙叢集備份增量同步的方案，對於網路頻寬，介質的讀寫效能有較高的要求，因此需要根據叢集規模和資料增量來選擇合適的組網方式和介質。

本文分享自華為雲社群《GaussDB(DWS)的容災應該如何設計》，原文作者：Puyol 。

點選關注，第一時間瞭解華為雲新鮮技