帶你認識數倉的增量備份核心設計-有解無憂

摘要：增量備份是重要的常規備份策略，正確快速識別增量變化檔案的相關資訊對增量備份至關重要，

本文分享自華為云社區《其疾如風，GaussDB（DWS）增量備份核心設計》，作者：我的橘子呢，

1、認識增量備份

GaussDB(DWS)數倉的備份恢復工具Roach支持集群級增量備份，全量備份會將源資料完整備份，而增量備份僅將上次備份后所作的更改進行備份，這里的上次備份可以使全量備份，也可以是全量備份后的增量備份，需要注意的是，增量備份的基礎始終是全量備份，如果一次全量備份之后進行了全量恢復，則不能再基于該全量備份進行增量備份，必須重新進行全量備份然后基于新的全量備份進行增量備份，增量備份分為兩種：累積增量備份和差分增量備份，

累積增量備份：如果一次全量備份后的多次增量備份，指定的prior-backup-key始終為全量備份的backup-key，即所有的增量備份都是基于全量備份來進行的，那么這些增量備份就是累積增量備份，累積增量備份均是基于最近一次全量備份進行的，如圖1所示，

圖1 累積增量備份示意圖

差分增量備份：如果一次全量備份后的多次增量備份，指定的prior-backup-key均為上一次備份（可能是全量備份也可能增量備份）的backup-key，即此次備份是基于上一次備份集來進行的，那么這些增量備份就是差分增量備份，差分增量備份均是基于最近一次備份進行的，如圖2所示，

圖2 差分增量備份示意圖

2、增量備份之CBM設計

增量備份只需要備份上一備份節點到當前時間發生變化的資料檔案，為了實作備份資料的完整性與一致性，正確識別并備份增量資料檔案是至關重要的，作為增量備份的核心設計，Gauss資料庫內核的事務日志功能與cbm設計可以幫助Roach工具快速準確識別增量期間資料檔案的變換資訊，為快速準確完成增量備份提供了有力保障，

（1）WAL與事務日志

為了保證資料的一致性和完整性，在對資料進行相關操作之前都會將具體的操作記錄下來，持久化到可靠存盤中，然后再進行具體的資料操作，這就是所謂的WAL（Write Ahead Logging），記錄的相關操作稱為XLOG日志，每一條日志記錄都由LSN進行唯一標識，這樣做的好處是事物的記錄被提前記錄并保存起來，在因一些外部原因（比如斷電、作業系統失敗等）導致操作失敗后，我們可以通過保存的事物日志將這些操作重新執行一遍，保證資料不會丟失，相關操作如圖3所示，

圖3 WAL操作示意圖

（2）Checkpoint操作

當系統運行時間較長的時候，由于操作較多，日志檔案的數量也較多，如果每次利用日志進行恢復操作都會耗費大量的時間，為了節約時間同時減少不必要的恢復操作，引入了checkpoint的概念，checkpoint表示在此操作之前，相關資料已經被保存到永久存盤中，即使系統故障，這部分資料也不會丟失，因此恢復的時候只要從checkpoint操作之后根據日志執行恢復操作就可以了，checkpoint本身也是一條xlog記錄，該記錄包含了redo點的位置，因此，每次恢復資料時，先從xloh記錄里找到最近的一次checkpoint記錄，并根據該記錄找到相應的redo點位置，這就是執行本次恢復的起始點位置，如圖4所示，checkpoint操作記錄了redo點的位置，

圖4 Checkpoint操作示意圖

（3）CBM設計

基于上述功能，由于資料的所有變化都被記錄在了xlog中，Gauss資料庫內核通過增加常駐的CBM writer執行緒，持續不斷地對新增的xlog進行決議，識別并記錄哪些資料資料頁面被修改，CBM記錄的生成程序如圖5所示，

圖5 CBM生成示意圖

CBM writer執行緒的作業流程為：

行程啟動時即開啟CBM writer功能
在startup執行緒剛啟動時，其根據已經決議出來的CBM檔案，來決定CBM writer開始決議的起始LSN位置，每次執行到checkpoint末尾是，會設定CBM writer執行緒的latch，CBM writer執行緒等待latch被設定，然后進行一輪日志決議，
通過動態reload GUC引數，開啟CBM writer功能
由于是動態開啟的CBM writer功能，因此startup執行緒沒有初始化CBM決議的起始位置，打開enable_cbm_writer開關的同時，會將CBM強制初始化的標志置為true，當CBM writer執行緒啟動之后，其第一次決議中，會強制初始化獲得決議的起始lsn，