摘要：大規模分佈式系統中的故障無法避免。當DN發生單點故障時，恢復手段有哪些，又是如何恢復的，本節重點介紹操作gs_ctl build是如何修復DN單點故障的。
本文分享自華爲雲社區《華爲雲數倉備機DN重建，快速修復DN單點故障!》，原文作者：welblupen。
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日誌量都更少，代價中等。
3.3. 全量清理重建： gs_ctl build -b fullcleanup -Z datanode
用途：
與full模式區別爲：同步前需要清理DN主機的數據目錄。能夠修復絕大多數數據和日誌損壞或丟失的場景，但修復時間比其他模式更長
過程：
- 清理備機數據文件：備機清空數據目錄，保留配置文件
- 主機向備機傳輸全量鏡像：主機使用單個線程將自己的數據目錄除了配置文件外，全部發給備機
- 完成全量重建等待xlog日誌落盤
分析：
全量清理重建是備機清空數據目錄，保留配置文件，向主機發送全量重建請求，主機將自己的數據目錄除了配置文件外，全部發給備機，重建後啓動備機，代價較大。
4. 總結
備機DN重建功能主要目的是單點故障修復，備機重建方式按照實現分爲全量重建，全量清理重建和增量重建，均和主DN進行交互。當DN出現單點故障時，操作人員應該根據實際損壞程度和資源消耗選擇合適的重建方法進行備機的數據重建。
想了解GuassDB(DWS)更多信息，歡迎微信搜索“GaussDB DWS”關注微信公衆號，和您分享最新最全的PB級數倉黑科技~