根據容災備份系統對備份類別的要求程度，資料庫備份系統可以分為資料級備份和應用級備份。資料備份是指建立一個異地的資料備份系統，該系統是對原本地系統關鍵應用資料實時複製。當出現故障時，可由異地資料系統迅速恢復本地資料從而保證業務的連續性。應用級備份比資料備份層次更高，即在異地建立一套完整的、與本地資料庫系統相當的備份資料庫應用系統，同時備份本地資料。可以同本地應用系統互為備份，也可與本地應用系統共同工作，在災難故障出現後，遠端應用系統迅速接管或承擔本地應用系統的業務執行。本文基於Rsync演算法設計實現資料庫應用級容災備份方案，並說明方案的部署及實施流程。

Rsync介紹

Rsync(remote synchronize)是一款開源的Linux/Unix遠端資料同步工具，可以通過網路快速同步多臺伺服器主機之間的檔案與目錄。其核心為“Rsync演算法”，它由澳大利亞計算機工程師Andrew Tridgell發明。演算法思路利用差分計算兩個檔案不同編碼值，並將該編碼值傳給同步原始檔，來獲取兩個檔案在不進行檔案內容直接網路傳輸的情況下知道兩個檔案的不同和相同之處，從而僅僅對檔案的不同內容進行同步傳輸，以減少網路資料傳輸量，進而提高傳輸效率達到同步檔案的效果。演算法核心包括了Checksum演算法、傳輸演算法、Checksum searching演算法、對比演算法。

Checksum演算法首先會把同步目標檔案平均切分成若干個小塊，比如每塊512個位元組（最後一塊會小於這個數），然後對每塊計算兩個校驗和（Checksum）：

• 一個叫滾動校驗和（rolling checksum），為32位弱校驗和，使用adler-32演算法；
• 另一個為強校驗和（md5 checksum），採用128位的md5 Hash演算法；

通過弱滾動校驗和來快速計算出兩檔案塊的不同，但該演算法碰撞概率較高。因此，通過引入強checksum校驗和來計算兩檔案塊的相同。

檔案塊的校驗和計算完畢後，會將一個checksum列表傳輸給同步原始檔，包括rolling checksum(32bits)、md5 checksum(128bits)、檔案塊編號。原始檔會進行同樣的校驗和演算法計算，並與列表進行對比發現檔案的不同和相同之處。

同步原始檔通過採用checksum searching演算法來查詢，將目標檔案的checksum列表資料存放在一個16bits的hash table中，採用rolling checksum做hash值，以便獲得時間複雜度的查詢效能。Hash table的大小為216，對rolling checksum的hash會被雜湊到0到216-1中的某個整數值。對hash值發生碰撞的則做成一個連結串列進行存放。

最複雜關鍵的為檔案塊的對比演算法。同步原始檔將自身的檔案塊進行checksum計算後，從hash table中進行查詢。如果查到了則說明發現了相同的檔案塊資訊，再計算比較md5的checksum，如果md5 checksum再相同則說明目標檔案中存在相同的檔案塊，並記錄檔案塊編號。如果沒有查詢到則說明檔案塊資訊不同，也不用再計算md5 checksum值。總之，只要rolling checksum或md5 checksum其中有不匹配的項，那麼對比演算法就會對檔案塊進行rolling動作，演算法會往後跳1個位元組，取2-513位元組的檔案塊計算checksum，重複進行相關的查詢對比，直到完成整個源同步檔案的對比。通過對比演算法可以找出相鄰兩次匹配中的那些文字字元不同，則需要同步傳輸給目標檔案。對比演算法流程如圖1所示：

圖1.對比演算法流程說明

圖2.資料陣列表示例

Rsync是一個客戶端與服務端架構部署的網路結構。Rsync服務端指執行rsync deamon守護程序的伺服器，並設定備份目錄來儲存同步目標檔案；Rsync客戶端則發起rsync連線的伺服器，存放備份的同步原始檔。Rsync的備份伺服器體系結構如圖3。

圖3.Rsync備份伺服器體系結構

Rsync工具不僅提供了高效快速的增量同步演算法，對於資料庫備份還具備許多完善、靈活的功能特性：

• 支援備份更新目錄和檔案；
• 適合資料儲存結構大檔案的增量同步備份，減少備份傳輸耗時；
• 對多個同步檔案內部以流水線減少檔案等待延時；
• 支援多種網路環境下rsh、ssh、nfs、socket埠等傳輸方式，可靈活支援資料庫的加密、壓縮等檔案特性；
• 適合資料庫映象備份，支援匿名傳輸；
• 支援資料庫備份資料可靈活保持連線、檔案屬性、許可權、裝置以及時間等；

資料庫備份思路

一個數據庫的資料庫備份必須是一個數據庫的完整的映像，在這個映像的時間點上，沒有部分完成的事務存在。因此，資料庫備份設計方案必須要求資料庫支援在某時刻資料庫的靜止狀態或不會對資料映象檔案進行重新整理，希望對資料庫系統完成線上資料庫備份操作，實現資料庫系統高效能的應用級備份。

方案設計思路採用Rsync工具對備份資料庫各節點的資料從生產資料庫系統上進行增量同步，由於生產資料庫系統和備份資料庫系統是拓撲結構完全相同的兩個環境，因此生產資料庫和備份資料庫之間節點存在相對應的關係。如果在對應節點之間建立起同步關係，只要保證每個節點上的表結構、資料、日誌記錄等保持一致，那麼整個資料庫系統環境總體的表結構、資料和日誌等也會一致。整個備份方案設計流程分為備份初始化、增量同步備份、備份恢復。以此來實現資料庫系統的線上備份，並支援應用系統通過網路對備份資料庫系統的切換和請求。

備份方案設計

通過以資料庫叢集的線上備份為例對設計方案和實施流程進行說明。

資料庫備份方案一般主要考慮到資料庫系統備份、應用系統訪問切換、ETL資料業務流程備份等，整體網路拓撲結構可簡單如下圖所示。

圖4.整體網路拓撲圖

備份系統之間網路為確保資料的及時性可採用區域網或都會網路，一般推薦提供萬兆以上專用網路。應用系統訪問可採用HA專用網路裝置或DNS軟體技術等對備份資料庫系統進行切換，同時ETL資料業務流程則通過對控制檔案進行備份，確保業務在故障狀態下對備份資料庫系統的操作。最核心的資料庫系統備份則需根據資料庫集群系統的特點，以及Rsync備份伺服器體系結構進行設計，其網路結構部署圖如下。

圖5.資料庫叢集備份設計方案部署圖

備份資料庫系統在資料庫叢集伺服器各節點上部署執行備份資料庫叢集軟體和Rsync Server程式，機器節點稱為備份伺服器。所有備份伺服器節點需要啟動Rsync守護（daemon）程序，等待客戶端Rsync連線。同時，原生產資料庫系統叢集節點部署Rsync Client服務程式，為Rsync客戶端伺服器，在啟動備份操作時向備份伺服器傳送同步請求。生產資料庫系統在備份操作啟動之前確保資料庫系統處於靜止狀態，生產資料庫叢集節點與備份資料庫叢集節點採用一對一方式進行資料的增量同步備份。

實施流程

圖6.備份初始化流程

1、備份初始化

1. 首先確認備份資料庫叢集軟體系統環境的正常安裝部署，並分別在生產資料庫系統叢集各節點和備份資料庫系統叢集各節點上部署Rsync軟體環境，生產資料庫叢集為Rsync客戶端，備份資料庫叢集為Rsync服務端。
2. 檢查和驗證備份系統初始化前的網路環境，確認備份系統網路與生產網路環境的互通性，可以通過網路測試工具或網路命令方式進行驗證。檢查確認生產資料庫叢集狀態是否正常。
3. 待生產資料庫系統進行狀態確認一致後，對生產資料庫系統叢集模式設定為只讀（靜止）模式，生產資料庫系統叢集僅對外提供查詢功能，不進行DDL、DML等資料更新操作，使其資料映象檔案處於靜止狀態，為備份初始化資料的初次同步做好準備。首次備份初始化的時間點主要選定在生產資料庫系統業務流程執行前的閒暇時間段來進行，根據業務系統的特點和備份資料量的預估，儘量減少對生產資料庫叢集業務流程執行的影響。
4. 啟動備份初始化同步程式，通過生產資料庫系統叢集與備份資料庫系統叢集之間萬兆網路來進行資料同步。作為初始化備份同步方式採用SCP命令，主要是為了節省備份所需的備份時間和系統資源消耗。另外由於Rsync工具需要Rsync差分抽取演算法支援，所以演算法執行過程中會消耗更多的資源和通訊代價，從而也使初始化備份的時間週期更長。初始化同步時間可以通過以下計算公式評估得出。例：估算備份初始化資料量規模大小，例如為D（單位TB）。資料庫系統環境由多個（N）叢集節點通過SCP命令方式傳輸，同步資料到備份資料庫系統各叢集節點伺服器上。按照網路傳輸同步速率為1TB/小時（考慮到網路利用率和資料在磁碟上落地時間等工程經驗總結數值），初始化資料同步耗時=總資料量/節點數/網路傳輸速度（TB/小時）= D / N / 1（TB/小時），工程估算200TB初始化同步資料耗時為8小時左右。
5. 確認備份初始化資料同步是否成功。如果成功，則修改生產資料庫系統叢集模式設定為正常模式，恢復生產資料庫系統叢集正常對外提供資料操作的能力。
6. 啟動備份資料庫系統服務，驗證備份資料庫系統叢集資料是否一致性。如果失敗，則人工確認查詢故障問題，重新進行初始化資料同步。

圖7.增量同步備份流程

2、增量同步備份

1. 啟動定時增量同步備份程式。首先驗證生產資料庫系統狀態，確認各個節點狀態和資料一致性正常。將生產資料庫系統叢集模式設定為只讀（靜止）模式，僅對外提供資料查詢操作，暫不支援DDL、DML等資料更新操作。同時停止備份資料庫系統，不對外提供任何服務，防止增量資料同步過程中操作帶來的問題。增量同步啟動時間點可由應用系統特徵和業務需求，選擇按分鐘、小時、天為週期來進行。
2. 排程執行Rsync增量同步程式，通過網路NFS方式對備份資料庫系統叢集各節點的資料檔案目錄一對一進行增量同步傳輸。增量同步耗時計算方式如下：以變動和增加資料量規模為S（單位TB）計算，同步資料量S通過均分給叢集N個節點，網路每小時同步傳輸為1TB。則正常增量同步情況下每天整個資料庫系統叢集耗時為=S / N / 1（TB/小時），工程估算1TB增量資料大約耗時1分鐘左右。
3. Rsync完成增量同步後驗證資料同步狀態，檢查各個節點Rsync同步結果返回值，為0表示成功，其它值則表示失敗。如果失敗，則重新通過Rsync進行增量同步，Rsync工具會自動重新對比生產資料庫系統資料檔案來進行同步。當驗證資料增量同步失敗次數大於3次後則通過簡訊介面告知系統運維人員增量同步異常，人工查詢故障問題。同時對生產資料庫系統叢集模式設定為正常模式，而備份系統叢集狀態則保持停止狀態。（這樣可以首先確保生產叢集環境能恢復對外提供資料操作能力，而備份系統叢集環境可以在之後由人工確認錯誤原因，在下次的同步處理中解決同步異常問題）。增量同步失敗重試次數通過全域性靜態引數進行設定，支援靈活修改。該引數主要考慮Rsync重試帶來的正常增量同步耗時影響，重試次數過多會增加生產系統叢集無法對外提供資料操作的時間；重試次數過少，將產生頻繁對備份異常進行報錯，增加人工維護和操作工作任務。
4. 如果成功，則將生產資料庫系統叢集模式設定為正常，恢復生產系統正常對外提供資料操作。
5. 驗證備份資料庫系統叢集狀態和資料一致性情況，如果資料狀態為0則正常，為1則不正常。

圖8.備份恢復流程

3、備份恢復

1. 當生產資料庫系統叢集產生故障時，首先停止該資料庫叢集服務，並將生產資料庫系統脫離生產業務網路環境。
2. 切換應用系統訪問介面程式和ETL業務流程平臺命令。應用系統訪問介面程式通過HA專用網路裝置或DNS軟體技術對JDBC驅動連線字串IP地址進行修改來切換，需要將原生產資料庫系統的各服務節點IP地址替換為備份資料庫庫系統下各服務節點的IP地址。ETL業務流程平臺則通過修改控制檔案中對資料庫環境的指定。
3. 備份資料庫系統叢集對外提供生產業務服務，並重新執行上一個備份點後的資料載入和ETL業務流程過程，確保生產業務的連續性。
4. 人工對生產資料庫系統叢集進行故障解決和恢復。
5. 啟動恢復後的生產資料庫系統叢集環境，並連線生產業務網路環境。按照備份資料庫系統叢集切換流程重新將應用系統訪問介面程式和ETL業務流程切換到恢復後的生產叢集環境上，切換流程與備份資料庫系統相似。
6. 恢復生產資料庫系統叢集環境後，還需對故障後所有的資料載入和ETL業務流程進行重新執行，確保生產叢集的整體資料一致性和業務實時性。

方案優勢及不足

基於Rsync演算法的資料庫備份設計方案實現了資料庫系統的線上備份能力及應用級切換功能，主要優勢在於：資料庫備份過程中採用Rsync演算法靈活高效的實現了資料庫資料檔案的增量備份，極大減少了日常備份所耗費的時間；方案可支援主流大多數Linux、Unix作業系統，並靈活地選擇或設定備份資料檔案及目錄樹；允許備份過程中對生產系統資料庫進行查詢統計操作；滿足備份資料庫系統的線上切換，且設計方案具有較高的價效比。

方案的不足之處在於資料庫系統對每個叢集節點的同步是完全獨立於其它節點的，因此務必所有叢集節點的增量備份成功，才能確保叢集整體增量備份的成功。且生產系統資料庫無法做到任意時間點的實時備份同步。

結束語

基於資料庫的線上備份功能及技術一直是資料庫產品研究的重點和難點。方案摒棄了傳統關係型資料庫採用日誌備份的思路，對映象資料檔案進行增量備份的方式來實現。充分利用Rsync演算法的優勢和開源技術，結合分散式資料庫的場景特點，提出了一種切實可行的備份設計方案。