摘要：針對數據同步狀態查看方法，GaussDB(DWS)提供了豐富的系統函數、視圖、工具等可以直觀地對同步進度進行跟蹤，尤其是為方便定位人員使用，gs_ctl工具已集合了大部分相關系統函數的調用，可做到在任何時間，從未啟動、啟動、重建到運行時的關鍵信息顯示。
1 背景概述：
1.1DN高可用架構模型
要理解或描述數據同步的過程機制，需要首先要了解GaussDB(DWS)的DN高可用架構，理解涉及數據同步的各組件的關系、數據類型、數據流向、設計原理和目的。
GaussDB(DWS)的DN高可用架構為主、備、從備架構。即在分布式環境中，完整的集群數據采用分片技術分布在多個DN組上，每組DN承擔一個數據分片，包括：一個主DN、一個備DN和一個從備DN。主和備各有一份完整的數據，從備上一般不存儲數據，僅在備機故障時做數據的暫存。組件之間關系如圖1所示：
圖1 DN高可用架構關系圖
主、備、從備高可用架構下，主、備及主、從備之間均會建立流復制通道。流復制又分為日志復制和數據頁復制。日志復制用於同步主DN由於WAL機制刷到磁盤上的XLOG，同步到備DN進行回放。數據頁復制用於同步批量導入的行存數據、或列存CU文件。需要注意的一點是，從備僅用於存放XLOG和數據，回放（replay）僅發生在備DN上。
1.2 數據同步涵蓋范圍
數據同步就是涉及集群中主、備節點以及從備節點之間的日志復制數據的傳輸、回放，數據頁復制數據的傳輸、追趕，備機重建等過程。GaussDB(DWS)集群高可用實踐WAL（Write Ahead Logging）思想，並通過各組件的主備的數據同步、倒換、重建等機制，保證數據庫單實例遭遇Crash后，具備故障恢復及自愈的能力，保護數據庫中數據的可靠性和完整性，最終實現集群對外業務連續性的過程。
這些主要的過程有：
（1）主備之間的正常流復制
每組DN獨立承擔一個數據分片，因此要求各個DN主與備必須強同步。為保證DN的主備強同步，數據在主DN操作時產生日志，事務提交時將日志同步給備DN。備機對接收到的XLOG進行回放（replay），將日志轉為數據。另外，列存和行存批插場景下，備機正常時，新增（變更）數據會發往備機。使用數據頁同步相對於日志同步少了磁盤IO，可以提升同步效率，減小RTO。
（2）備機追趕
為了解決單節點故障后集群寫事務可用，DN的高可用設計引入從備這個實例。一旦備DN故障，數據將發送給從備，仍然保證了數據寫兩份的原則，事務照樣可以提交。但主機會對BCM文件里面的標記位置狀態位。BCM文件中每一bit位（除預留位外）對應數據文件中每一頁（8k）狀態。
當備機重新啟動的時候，會連接主機做數據頁追趕（catchup）。追趕機制分為全量和增量兩種。全量catchup機制，不依賴於從備，主機遞歸掃描本地默認表空間和自定義表空間下的所有BCM文件，然后查看狀態位來確認哪些數據文件需要發送給備機。增量catchup機制依賴於從備，主機通知從備遍歷其從備上暫存的數據頁，將變更的數據頁列表發往主機，主機直接按照從備發來的變更列表，將變更數據發往備機。
（3）主備倒換
當主DN故障時，需要對備DN進行failover，failover后備DN升為主DN來接管業務。所以failover時，備DN需要連接從備DN，向從備DN請求數據，以補齊備DN比主DN缺少的數據。failover的過程是備DN獨立完成的，不需要和主DN進行交互。
（4）備機重建
重建功能主要目的是單點故障修復，備機重建方式按照實現分為全量重建和增量重建，均和主DN進行交互。全量重建是備機清空數據目錄，保留配置文件，向主機發送全量重建請求，主機將自己的數據目錄除了配置文件外，全部發給備機，重建后啟動備機。增量重建是一種以主DN文件為基准，按照文件塊對備DN文件進行校驗，如果備DN文件的某個文件塊校驗不一致，則主機將此文件塊發給備DN，寫入文件對應的文件塊中。與全量重建相比較，拷貝的數據量和WAL日志量都更少，代價更小。
從以上這些數據同步過程中，我們發現表現在運維上一個明顯的特點是，這些過程有可能會時間花費較長，一旦同步過程中出現異常問題，其內部關鍵過程信息輸出對於問題分析定位十分重要。因此，GaussDB(DWS)提供了豐富的系統函數、視圖、工具等可以直觀地對同步進度進行跟蹤，尤其是為方便定位人員使用，gs_ctl工具已集合了大部分相關系統函數的調用，可做到在任何時間，從未啟動、啟動、重建到運行時的關鍵信息顯示。
2 方法總結
2.1 系統視圖
總結涉及數據同步的系統視圖如表1所示。具體參數、返回值定義請參考相應版本的產品文檔手冊。
2.2 系統函數
總結涉及數據同步的系統函數如表2所示。具體參數、返回值定義請參考相應版本的產品文檔手冊。
2.3 常用工具
總結涉及數據同步的常用工具如表3所示。具體工具說明、參數定義請參考相應版本的產品文檔手冊中的定義。
3 應用場景
3.1 查看DN實例Redo進度
當DN實例crash發生時，我們可以通過回放XLOG日志中記錄的數據變化還原crash前的操作。這個就是所謂的redo/recovery過程。如果需要redo的XLOG比較多，或者遇到某種特殊日志類型，對DN實例進行啟動，啟動過程時間就會有些長。
DN實例啟動過程中，如果期望查看XLOG redo的進度。最方便的是使用gs_ctl query工具對指定DN實例路徑進行狀態查詢，結果中可以顯示xlog redo的進度，如圖2所示。此外，在DN實例可以接受gsql連接時（啟動到最小恢復點之前是拒絕連接的），也可直接在當前DN上執行pg_xlog_replay_completion 函數來獲取XLOG redo進度信息。
圖2 DN實例啟動時XLOG Redo進度查詢
啟動Redo進度相關信息（Xlog replay info）包括：
- replay_start：Xlog Redo的起始LSN 。DN實例啟動XLOG redo過程時，記錄replay_start。
- replay_current：Xlog Redo的當前replay的LSN。
- replay_end：DN本地接收到的最大XLOG lsn。
- replay_percent：Xlog Redo的當前完成的百分比。(replay_current - replay_start)*100 / (replay_end - replay_start)的計算值。
依據replay_current的變化，可以看到XLOG redo的推進。
依據replay_percent和啟動開始時間，可以推測DN實例啟動到正常狀態的所需時間。
3.2 查看備機Failover進度
當主機發生故障時，我們需要將備機failover成主機，此時備機需要連接從備同步XLOG和數據頁文件。如果需要同步的XLOG比較多，或者遇到某種特殊日志類型，或者數據文件比較多時，對備DN實例進行failover，過程時間就會有些長。
備機failover升主過程中，如果期望查看XLOG redo和數據頁文件同步的進度。最方便的是使用gs_ctl query工具對指定DN實例路徑進行狀態查詢，結果中可以顯示xlog redo的進度和從備數據同步的進度，如圖3所示。此外，在DN實例可以接受gsql連接時，也可直接在當前DN上執行pg_data_sync_from_dummy_completion 函數來獲取從備數據文件同步的進度信息。
圖3 備機Failover進度查詢
Failover Redo進度相關信息（Xlog replay info），字段含義同Start Redo，區別在於，備DN在處理failover請求連接從備時候獲取最新的replay lsn更新了replay_start。
Failover數據頁文件進度相關信息（Data sync from dummy）包括：
- start_index：數據頁文件同步的起始編號。
- current_index：數據頁文件同步的當前編號。
- total_index：數據頁文件同步的最大編號。
- sync_percent：數據頁文件當前完成的百分比。(current_index - start_index) *100/ (total_index - start_index + 1) 的計算值。
依據current_index的變化，可以看到數據頁同步的推進。
依據sync_percent和failover開始時間，可以推測DN實例failover到正常狀態的所需時間。
3.3 查看備機Catchup進度
當備機重新啟動的時候，會連接主機做數據頁追趕（catchup）。如果需要傳輸的數據頁比較多，或者因為業務造成的鎖沖突，catchup 時間就會比較長，備DN長時間不能成為Normal狀態。
如果期望查看數據頁catchup的進度，可以在CN上執行select * from pgxc_get_senders_catchup_time()可進行當前活躍的主備發送線程的追趕信息顯示，如圖4所示。
圖4 集群上catchup進度查詢
也可以在相應的主DN上執行select * from pg_get_senders_catchup_time可進行當前活躍的主備發送線程的追趕信息顯示。完成后，看到的是剛結束的catchup過程信息，如圖5所示。
圖5 主DN上catchup進度查詢
備機Catchup進度相關信息包括：
- catchup_type："Incremental"或者"Full"。catchup方式為全量還是增量。
- catchup_bcm_filename：當前主機正在處理的一個BCM文件名稱。
- catchup_bcm_finished：catchup已操作完成的BCM文件數量。
- catchup_bcm_total：catchup總共需要操作的BCM文件數量。
- catchup_percent：catchup已經操作完成的百分。catchup_bcm_finished*100 / catchup_bcm_total 的計算值。
- catchup_remaining_time：依據已完成的進度，預估剩余完成時間。
依據catchup_bcm_filename和catchup_bcm_finished的變化，可以看到數據頁追趕的推進。
依據catchup_percent和catchup_remaining_time，可以推測備DN實例追趕到正常狀態的所需時間。
3.4 查看DN實例XLOG空間使用狀況
隨着數據庫的不斷運行，產生的日志文件越來越多，如果因為節點故障或其它原因有可能造成日志文件不斷積累而充爆磁盤。為了解此使用信息，最方便的是使用gs_ctl query工具對指定DN實例路徑進行狀態查詢，結果中可以顯示該實例的XLOG空間使用信息，截圖示例請參見上面其它場景。此外，還提供系統函數 pgxc_stat_xlog_space、pg_stat_xlog_space 對數據庫集群或單個實例進行查詢，例如使用pgxc_stat_xlog_space可以獲取到整個集群的CN、主DN的XLOG空間使用信息，如圖6所示。
圖6 Xlog空間使用查詢
XLOG空間使用信息（Xlog space info）包括：
- xlog_files：pg_xlog目錄下，去除backup、archive_status等子目錄，所有識別為xlog文件的數目；
- xlog_size：pg_xlog目錄下，去除backup、archive_status等子目錄，所有識別為xlog文件的大小之和，以MB單位顯示；
- other_size：pg_xlog目錄下backup、archive_status等子目錄文件的大小之和，以MB單位顯示。