高效的并行數據庫備份和恢復工具

目錄

一、gpbackup/gprestore

二、gpcopy

Greenplum數據庫從5.5.0版本開始，基于內置的COPY……ON SEGMENT命令，發布了更加高效的基于Greenplum的gpbackup/gprestore實用工具。關于COPY……ON SEGMENT命令的詳細介紹，請參考6.1.1節。總的來說，gpbackup只存儲對象的元表文件和DDL文件，且備份文件的生成、壓縮和存儲是在每個Segment上完成的，因此更加高效。gpbackup的元表信息包含gprestore運行需要的所有信息。另外，把數據存儲為csv格式使得數據同樣可以被其他工具（比如gpload）加載到同一個集群或者另外一個集群。每一個gpbackup的任務使用單個Greenplum中的事務。在事務執行期間，元表信息會備份到Master節點，而數據文件則通過COPY……ON SEGMENT命令并行備份到Segment節點。在備份過程中，備份進程只會獲取備份表上的ACCESS SHARE表鎖，不會阻塞線上Greeplum對外正常提供服務。

具體來說，gpbackup相比之前的gpcrondump做了以下優化和增強：?減少對元表（catalog）的加鎖。?增強的監控管理和備份日志。?支持csv文件格式。?可插拔的第三方數據接口支持。?增強的對元表（catalog）的查詢性能。?并行同步備份的支持。?細粒度選擇備份對象（角色、函數等），而不是基于表級。?特殊字符支持（\t\n等）。?完全基于Go語言重寫，避免了Python多版本問題。

1）減少或優化對元表（catalog）的加鎖以提高Greenplum在線服務能力和備份性能：

?不對pg_class表加鎖，減少因為pg_class大鎖的競爭導致其他操作終止執行。

?不加表級的EXCLUSIVE鎖，只加表級的ACCESS SHARE鎖，從而減少對表的競爭訪問，提高并發量。

?基于多版本同步控制（MVCC），利用COPY語句在Segment上直接進行數據導入/導出。

?移植了PostgreSQL 9.1鎖的新特性，提高性能。

?提供可選的多種一致性級別，可根據使用場景靈活選擇。

2）增強備份過程中的監控管理和日志輸出：

?利用心跳來探測備份進程是否還在運行。

?備份進度指示條。

?保留歷史的進度信息，可用于估計本次備份所花的時間，以及判斷本次備份是否存在性能問題。

?可通過配置選擇性恢復指定數據文件。

?增強的備份結果報告文檔，并且對郵件報警部分進行改造。

3）COPY用于導入和導出數據：

?利用改進的COPY命令，可以直接并行運行在Segment上，而不需要像之前那樣通過Master單節點。

?更加靈活，可以為每個Segment的每個表生成獨立的csv文件，從而提高恢復的并行性。

4）可插拔的外部數據源API：

?可靈活支持各種第三方數據平臺，包括Data Domain、Commvault等。

?可支持各種基于云的存儲，包括AWS、Azure、GCP等。

?具備靈活性，可將備份數據對接到用戶提供的定制化程序。

?容災備份，可將備份數據對接到遠程Greenplum集群。

gpbackup/gprestore可支持的細粒度選擇對象如表

使用注意點：?如果用戶在分區表的父表上創建索引，備份時不會為子表備份出相應索引，因為在子表上創建相同的索引會導致錯誤。但是如果用戶使用過交換分區操作，gpbac-kup檢測不到新的子表上的索引是來自父表，恢復時可能會導致重復創建索引的錯誤。?用戶可以執行多個gpbackup，但是每個gpbackup擁有不同的時間戳。?數據庫對象的過濾目前只限于Schema和表。?如果用戶使用--single-data-file選項，那么每個Segment上的備份數據都會集中到一個文件中，在恢復時用戶就失去并行的可能性。?增量備份目前還只支持追加（Append Optimized）表和列存（ColumnOriented）表。

gpbackup不支持下列Schema下的數據備份：?gp_toolkit?information_schema?pg_aoseg?pg_bitmapindex?pg_catalog?pg_toast*?pg_temp*

運行完之后查看備份結果

master:

運行完上述命令后，可以看到在Master節點上全局和各個數據庫的元信息，其格式為$MASTER_DATA_DIRECTORY/backups//。

segment:

每個Segment節點在目錄/backups///下會存儲壓縮后的csv格式的備份數據：

如何恢復？

恢復過程中必須通過--timestamp選項指定，同時可指定--create-db選項使得恢復過程有助于重建缺失的數據庫。

gpbackup 提供了多個參數，可以使用 --help查看.

如果只需要備份表結構，則可以使用--metadata

試想一下？如果兩個集群的規模不一致，那gpbackup / gprestore還能用嗎？

答案是否定的.會有如下報錯

但是既然生成metadata的sql已經存在了。那么可以使用 psql來重放sql來實現。例如

-a, --echo-all echo all input from script -f, --file=FILENAME execute commands from file, then exit

因為psql 的輸出都是標準輸出，因此可以將其重定向到log中。

2>&1 代表的是將標準錯誤輸出和標準輸出合并 輸入到import_metadata.log

實際業務場景如下

?升級：16節點的Greenplum 4.3集群遷移到16節點的Greenplum 6.x集群

?遷移：8節點的Greenplum4.x集群遷移到16節點的Greenplum 6.x集群

GPCOPY可以遷移整個集群，也可以傳輸某些數據庫、命名空間和表；可以從正則表達式匹配需要傳輸的數據表；可以略過、追加或者替換目標集群的數據；可以并行傳輸；可以只遷移數據表的定義信息。GPCOPY利用了Greenplum的COPY…ON SEGMENT特性，基于Segment間直接傳輸數據獲得性能加速。

GPCOPY會在源端和目標端同時執行COPY…ON SEGMENT命令。該命令會被Master下發到每個Segment，在其上執行COPY命令。源端Segment會創建到目標端Segment的連接。當連接創建成功后，源端Segment執行COPY TO命令，將數據表的內容通過連接發送出去，而目標Segment執行COPYFROM命令，從連接上等待接收源端傳過來的內容。如果開啟了壓縮選項，在數據發送前會進行壓縮，數據接收后會先進行解壓縮。在數據傳輸過程中，在源端和目標端都各自開啟了數據庫事務，如果傳輸中間有錯誤發生，也可以保證數據的完整性。

GPCOPY的核心功能包括以下幾點：

1）Snappy壓縮傳輸。GPCOPY默認打開壓縮選項，使用Google的Snappy格式對所傳輸的數據進行壓縮，網絡傳輸壓力更小，速度也更快。Snappy對大多數數據的壓縮比zlib的最快模式還要快幾個數量級。在Core i7的單核64位模式下，Snappy壓縮速度可以達到250MB/s或更快，解壓縮可以達到大約500MB/s或更快。

2）高效好用的數據校驗。判斷兩個數據庫系統的表是否一致不是一個簡單的問題，使用哈希校驗的話要考慮條目的順序，使用排序的話又會降低速度。如果這兩個數據庫系統和Greenplum一樣是集群系統，這個問題就更難解決了。而GPCOPY靈活地解決了這個問題，既不需要排序，數據校驗的速度又比通過導出csv數據文件進行哈希快幾倍。

3）完善的日志記錄和錯誤處理。GPCOPY將數據傳輸過程中每一步的操作、執行的查詢、命令和結果都寫到日志文件中，并根據用戶指定的級別顯示到標準輸出。數據遷移操作通過事務塊進行保護，發生錯誤時可以做到表一級的回滾。運行結束時會有詳細的成功或失敗的總結信息，同時生成和提示用戶運行命令去重試所有發生過錯誤的操作。用戶環境如果出現錯誤，結合GPCOPY和Greenplum的日志文件，可以迅速地定位問題，保障數據遷移順利進行。

4）GPCOPY用于升級。Greenplum版本升級一般會有catalog變化，只升級可執行文件會導致數據不兼容，利用GPCOPY則可以做到原地升級。另外，因為有了快速好用的數據校驗，用戶也可以放心地一邊遷移數據一邊釋放空間。對于磁盤空間緊張的用戶，不再需要準備雙倍空間用于升級，節省了系統資源。

5）支持不同節點數的Greenplum集群間傳輸。從上圖可以看到，當目標集群和源集群節點數不同時，也可以使用GPCOPY進行高效數據遷移。

?--analyze：數據遷移結束后，是否需要對數據表進行Analyze操作。執行Analyze操作需要花費一些時間，但是會生產準確的統計信息供查詢優化器使用，以生成更加高效的查詢計劃。默認關閉。

?--jobs：數據遷移時指定的并行度。數據會分批次遷移，該選項指定每批遷移多少個表。

?--metadata-only：只在目標數據庫中創建表的定義，不進行實際的數據遷移。

?--truncate：如果目標數據庫中相同名字的數據庫表已經存在，是否在開始遷移前清空目標數據庫表的數據。

?--append：如果目標數據庫中相同表名字的數據庫表已經存在，是否保留之前的數據。該選項與--truncate互斥。