雙集羣原理

GaussDB(DWS) 的容災方案是一個雙集羣同步的架構，即兩套獨立集羣按期同步數據以達到容這的目的。目前數據同步的方式是經過roach(GaussDB(DWS)備份、恢復工具)按期作增量備份和恢復同步。雙集羣框架是一個複雜的分佈式系統，在出現問題時，如何快速準確的定位問題及恢復服務是一個很是緊迫的問題，這個問題在雲上會更突出。本文經過介紹雙集羣的架構、log結構、分析步驟來介紹雙集羣容災的問題分析方法。框架

首先介紹一下雙集羣的部署方案原理，從部署架構和重要參數兩個方面先介紹一下背景知識，便於更好理解問題分析的方法。分佈式

架構簡介

1. 邏輯架構示例

下圖是一個同構的雙集羣部署示意圖，主備集羣都是3c3d, 主集羣的主結點部署雙集羣框架腳本，按期進行備份操做，備集羣的主結點按期恢復備份集。基礎數據須要進行一全量備份，以後增量備份。工具

2. 部署架構

下圖是接上圖的部署架構，涉及雙集羣同步腳本(SyncDataToStby.py), 備份程序（GaussRoach.py, gs_roach）三個二進制文件學習

備份側調用關係：SyncDataToStby.py -> GaussRoach.py -> gs_roachurl

恢復側調用關係：SyncDataToStby.py -> GaussRoach.py -> gs_roachspa

瞭解調用關係和我們分析問題有直接的關係。.net

SyncDataToStby.py 是整個雙集羣的調用起始，控制着雙集羣的正常運行，正常狀況下是長駐內存的進程，若是異常退出後，後臺會有crontab的來從新拉起雙集羣腳本: crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach命令行

主要參數簡介

問題定位

衆所周知，系統的各類log是咱們瞭解運行機制，瞭解問題現場的有力工具，一樣雙集羣的問題分析也依賴於log的分析，首先認識一下雙集羣對應的日誌：

log 目錄結構

由上節的邏輯圖及部署圖，每一個二進制對應的log文件以下圖所示，對應二進制的信息查找對應的log。

如上圖，雙集羣的日誌也是存放到$GAUSSLOG這個目錄，而且有本身獨立的目錄 roach, 由這個目錄一樣是備份/恢復的對應的log路徑。咱們按調用關係從上到下的角度來介紹

1. frame目錄

存放 SyncDataToStby.py 生成的log，涉及到雙集羣調度，備份集清理，狀態顯示，配置文件及命令行參數解析的功能。

2. controller目錄

存放 GaussRoach.py 生成的log，涉及到備份、恢復準備工做一些操做，備份、恢復參數解析，備份集羣的處理，錯誤處理等

3. agent目錄

存放 gs_roach工具生成的log，涉及到gs_roach 鏈接gaussdb/gtm/cm發起備份/恢復，生成備份集/恢復備份集等操做。

gs_roach工具功能：在備份側完成將cn/dn/gtm/cm的數據文件按順序打包成備份文件的功能，並生成備份集元信息文件; 恢復側根據元信息文件將備份集文件解壓到對應cn/dn/gtm/cm的數據目錄中。

定位步驟

1. 肯定問題在備份側仍是恢復側，查找雙集羣主結點上Sync日誌，肯定出錯的模塊

2. 肯定出錯的層次，因爲雙集羣執行過程是一個上下層調用及時序關係的方式，具體順序參考：

crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach

3. 在各個模塊都有較詳細的日誌描述過程，具體問題具體分析，大致有以下幾個方面

1）配置出錯，用戶、環境變量文件

2）備份集羣路徑權限問題

3）因爲集羣狀態非Normal致使備份失敗

4）結點故障及備份集損壞致使恢復失敗

4. 後續文章會按模塊及錯誤類型來詳細描述問題定位步驟

小結

GaussDB(DWS)的雙集羣容災功能是一個獨立的複雜的分佈式系統，涉及到三層工具的使用，所以在問題定位時會形成一些困惑。定位的方法須要先去理解架構，運行機制，而後根據時序關係去對應結點分析日誌。後續會從各個模塊的角度介紹一些典型的問題及修復方法。

想了解GuassDB(DWS)更多信息，歡迎微信搜索「GaussDB DWS」關注微信公衆號，和您分享最新最全的PB級數倉黑科技，後臺還可獲取衆多學習資料哦~

點擊關注，第一時間瞭解華爲雲新鮮技術~