摘要：大規模分佈式系統中的故障沒法避免。當DN發生單點故障時，恢復手段有哪些，又是如何恢復的，本節重點介紹操做gs_ctl build是如何修復DN單點故障的。
本文分享自華爲雲社區《華爲雲數倉備機DN重建，快速修復DN單點故障!》，原文做者：welblupen。node
1. 技術背景
GaussDB(DWS)的DN高可用架構爲主、備、從備架構。即在分佈式環境中，完整的集羣數據採用分片技術分佈在多個DN組上，每組DN承擔一個數據分片，包括：一個主DN、一個備DN和一個從備DN。主和備各有一份完整的數據，從備上通常不存儲數據，僅在備機故障時作數據的暫存，當備機故障恢復以後，爲了保持集羣數據的一致性，須要備機鏈接主機進行數據和xlog日誌的拷貝。算法
2. 備機DN須要進行重建的場景
2.1. 主機發生單點故障以後，備機進行failover升主，原主降備，集羣降級；待原主故障恢復後，可能會致使主備機WAL日誌CRC校驗失敗，CM系統檢測到該狀態後會自動經過備機重建的方式進行自動備機重建。
2.2. 備機發生單點故障以後，備機狀態變爲unknown，集羣降級，待備機故障恢復以後，需須要進行備機重建操做同主機同步數據。
3. 備機DN重建的操做分類
3.1. 增量重建： gs_ctl build -b incremental -Z datanode
用途：
增量build可修復常見的主機或實例故障致使的備機日誌分叉問題，也可修復部分數據文件丟失的問題，在重建過程當中發生主機異常，能夠手動回退有損恢復。微信
過程：
- 獲取差別文件：經過解析Xlog日誌獲取主備DN差別文件
- 備份與恢復：對主備差別文件進行嚴格進行原子化恢復和備份，過程當中出錯可恢復，排除錯誤後，可再次調用重入
- 傳輸文件：由備機建立指定（1-16）個線程從主機拉取差別文件
- 完成增量重建等待xlog日誌落盤
分析：
增量重建是，根據Xlog日誌計算主備DN差別文件，將文件發送給備DN,在備機數據沒有損壞的狀況下快速進行增量重建，代價較小。架構
3.2. 全量重建： gs_ctl build -b full -Z datanode
用途：
備機全量重建可以修復絕大多數數據和日誌損壞或丟失的場景，但修復時間比增量build更長分佈式
過程：
- 獲取差別文件：使用依據硬件調優的CRC-32C系列算法獲取主DN上相應文件的CRC校驗值，同時本地也進行對應操做，兩者比較得到差別文件列表
- 備份與恢復：默認無原子化，但會嘗試進行原子化恢復，忽略恢復結果成敗
- 傳輸文件：由備機建立指定（1-16）個線程從主機拉取差別文件
- 完成增量重建等待xlog日誌落盤
分析：
全量重建是一種以主DN文件爲基準，備DN文件同其進行校驗，若是備DN文件的某個文件塊校驗不一致，則主機將此文件塊發給備DN。與全量清理重建相比較，拷貝的數據量和WAL日誌量都更少，代價中等。ui
3.3. 全量清理重建： gs_ctl build -b fullcleanup -Z datanode
用途：
與full模式區別爲：同步前須要清理DN主機的數據目錄。可以修復絕大多數數據和日誌損壞或丟失的場景，但修復時間比其餘模式更長url
過程：
- 清理備機數據文件：備機清空數據目錄，保留配置文件
- 主機向備機傳輸全量鏡像：主機使用單個線程將本身的數據目錄除了配置文件外，所有發給備機
- 完成全量重建等待xlog日誌落盤
分析：
全量清理重建是備機清空數據目錄，保留配置文件，向主機發送全量重建請求，主機將本身的數據目錄除了配置文件外，所有發給備機，重建後啓動備機，代價較大。spa
4. 總結
備機DN重建功能主要目的是單點故障修復，備機重建方式按照實現分爲全量重建，全量清理重建和增量重建，均和主DN進行交互。當DN出現單點故障時，操做人員應該根據實際損壞程度和資源消耗選擇合適的重建方法進行備機的數據重建。.net
想了解GuassDB(DWS)更多信息，歡迎微信搜索「GaussDB DWS」關注微信公衆號，和您分享最新最全的PB級數倉黑科技~線程