資料庫技術丨GaussDB(DWS)資料同步狀態檢視方法
摘要：針對資料同步狀態檢視方法，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單位顯示。