Greenplum是分布式數據庫，這為備份帶來了一些困難。其本身提供了一個工具是gpcrondump，對其二進制備份工具gp_dump做了一些封裝，而gp_dump則是對pg_dump做了封裝，在每個節點上執行pg_dump完成數據的備份。在其每個節點的行為上，與PG類似，但其分布式的架構，則有值得了解的地方。 ## 備份方法 GP備份的工具gpcrondump是一個Python腳本，是對gp_dump的一個封裝。而gp_dump則負責整個備份過程的控制與結果處理，包括獲取元數據信息、啟動Segment節點備份、狀態維護等動作。 ## gpcrondump gpcrondump的詳細參數： ~~~ gpcrondump -x database_name [-s <schema> | -S <schema> | -t <schema>.<table> | -T <schema>.<table>] [--table-file=<filename> | --exclude-table-file=<filename>] [--schema-file=<filename> | --exclude-schema-file=<filename>] [-u backup_directory] [-R post_dump_script] [--incremental] [ -K <timestamp> [--list-backup-files] ] [--prefix <prefix_string> [--list-filter-tables] ] [-c] [-z] [-r] [-f <free_space_percent>] [-b] [-h] [-j | -k] [-g] [-G] [-C] [-d <master_data_directory>] [-B <parallel_processes>] [-a] [-q] [-y <reportfile>] [-l <logfile_directory>] [--email-file <path_to_file> ] [-v] { [-E encoding] [--inserts | --column-inserts] [--oids] [--no-owner | --use-set-session-authorization] [--no-privileges] [--rsyncable] { [--ddboost [--replicate --max-streams <max_IO_streams> [--ddboost-skip-ping] ] ] } | { [--netbackup-service-host <netbackup_server> --netbackup-policy <netbackup_policy> --netbackup-schedule <netbackup_schedule> [--netbackup-block-size <size> ] [--netbackup-keyword <keyword> ] } } ... ~~~ 更多參數請參考[官方文檔](http://gpdb.docs.pivotal.io/4320/utility_guide/admin_utilities/gpcrondump.html)，或者查看命令help。對于詳細的使用方法，這里不再討論。 gpcrondump以DB為單位進行備份，當一次收到多個DB的備份請求時，則每個DB順序依次進行備份。針對每個DB，gpcrondump會做一些預處理后，組織一個完整的gp_dump執行命令后執行。最基本的gp_dump命令如下： ~~~ "gp_dump -p %d -U %s --gp-d=%s --gp-r=%s --gp-s=p --gp-k=%s --no-lock" % (self.master_port, user_name, dump_path, report_path, timestamp_key) ~~~ gpcrondump不同的參數帶來不同的gp_dump命令，比如“–table-file”等。 ## gp_dump gp_dump是真正進行數據備份的主體。其操作的主要步驟如下： 1. 參數、數據對象的處理 除了對參數處理以外，這里的行為與pg_dump相似，會對需要導出的數據對象、依賴關系等進行處理。 2. 連接Master，獲取元數據信息 從這里，獲取每個Segment的信息，包括主機、端口、角色等。 3. 根據元數據連接到各個Segment和Master 根據第一步獲取的Segment信息，獲取角色為’p’的Segment和Master，保證連到的是活躍的節點。針對每個Segment或Master，會單獨啟動一個線程進行連接。 在連接到節點后，會創建消息通知機制。通過不同的消息通知，對該節點的備份情況進行及時響應，并對整體的備份及時做出調整，如取消等。 之后，將gpcrondump組織的參數，組織成gp_backup_launch函數的入參，調用執行。 4. 之后調用gp_backup_launch函數，在Segment端啟動一個Agent進程 根據參數的不同，gp_backup_launch函數會啟動不同的獨立Agent進程。默認的是gp_dump_agent，這個Agent會封裝pg_dump。GP也支持備份到Data Domain Boost等外部存儲，即在獨立的Agent進程中調用不同的agent工具。 gp_backup_launch函數會等待gp_dump_agent執行結束后返回結果。 5. 每個Segment端啟動的Agent進程會再次連接到自身 Agent的實現與PG的pg_dump基本類似。不同的是，在參數處理之后，會將這個節點的隔離級別設置為串行。因此，多少會對備份期間的事務性能產生一定影響。而如果只是查詢的話則影響不大。 pg_dump和gp_dump_agent的實現都是用COPY或者FETCH語句將表的數據導出。 6. 結果返回 在gp_dump_agent執行結束后，結果返回作為每個節點上gp_backup_launch函數的執行結果。 7. 節點連接線程維護狀態機 gp_dump連接到每個節點的線程啟動運行狀態機，檢查其他并行線程的狀態、監聽當前線程的通知，當任何一個出現失敗，即取消備份 ## 時序圖  ## 總結 GP備份的機制充分利用了每個節點的并行，可以極大的提高備份速度。一方面單個節點的數據量可以控制在一定范圍，另一方面不同節點之間并行互不影響。 而在分布式中，比較麻煩的是保持多節點事務一致性和異常情況的處理。其中事務一致性是通過在每個節點上開啟事務并設置隔離級為串行做到；異常情況則是通過多線程之間通信和PG的消息通知來實現。 Hope you have fun.