目录
一、gpbackup/gprestore
二、gpcopy
一、gpbackup/gprestore
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*
1.1 实战
bin]$ gpbackup --dbname qmsprd 20210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-gpbackup version = 1.20.220210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-Greenplum Database Version = 6.2.1 build commit:d90ac1a1b983b913b3950430d4d9e47ee8827fd420210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-Starting backup of database qmsprd20210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-Backup Timestamp = 2021022315312020210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-Backup Database = qmsprd20210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-Gathering table state information20210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-Acquiring ACCESS SHARE locks on tablesLocks acquired: 82 / 82 [==============================================================] 100.00% 0s20210223:15:31:20 gpbackup:gpadmin:gptest01:003409-[INFO]:-Gathering additional table metadata20210223:15:31:21 gpbackup:gpadmin:gptest01:003409-[INFO]:-Getting partition definitions20210223:15:31:21 gpbackup:gpadmin:gptest01:003409-[INFO]:-Getting storage information20210223:15:31:21 gpbackup:gpadmin:gptest01:003409-[INFO]:-Getting child partitions with altered schema20210223:15:31:21 gpbackup:gpadmin:gptest01:003409-[INFO]:-Metadata will be written to /gpmaster/gp/master/gpseg-1/backups/20210223/20210223153120/gpbackup_20210223153120_metadata.sql20210223:15:31:21 gpbackup:gpadmin:gptest01:003409-[INFO]:-Writing global database metadata20210223:15:31:21 gpbackup:gpadmin:gptest01:003409-[INFO]:-Global database metadata backup complete20210223:15:31:21 gpbackup:gpadmin:gptest01:003409-[INFO]:-Writing pre-data metadata20210223:15:31:22 gpbackup:gpadmin:gptest01:003409-[INFO]:-Pre-data metadata metadata backup complete20210223:15:31:22 gpbackup:gpadmin:gptest01:003409-[INFO]:-Writing post-data metadata20210223:15:31:22 gpbackup:gpadmin:gptest01:003409-[INFO]:-Post-data metadata backup complete20210223:15:31:22 gpbackup:gpadmin:gptest01:003409-[INFO]:-Writing data to fileTables backed up: 82 / 82 [=========================================================] 100.00% 6m28s20210223:15:37:50 gpbackup:gpadmin:gptest01:003409-[INFO]:-Data backup complete20210223:15:37:51 gpbackup:gpadmin:gptest01:003409-[INFO]:-Found neither /usr/local/greenplum-db/./bin/gp_email_contacts.yaml nor /home/gpadmin/gp_email_contacts.yaml20210223:15:37:51 gpbackup:gpadmin:gptest01:003409-[INFO]:-Email containing gpbackup report /gpmaster/gp/master/gpseg-1/backups/20210223/20210223153120/gpbackup_20210223153120_report will not be sent20210223:15:37:52 gpbackup:gpadmin:gptest01:003409-[INFO]:-Backup completed successfully运行完之后查看备份结果
master:
运行完上述命令后，可以看到在Master节点上全局和各个数据库的元信息，其格式为$MASTER_DATA_DIRECTORY/backups/
segment:
每个Segment节点在目录
如何恢复？
恢复过程中必须通过--timestamp选项指定，同时可指定--create-db选项使得恢复过程有助于重建缺失的数据库。
~]$ gprestore --timestamp 20210223153120 --create-db20210223:16:19:19 gprestore:gpadmin:gptest01:044186-[INFO]:-Restore Key = 2021022315312020210223:16:19:19 gprestore:gpadmin:gptest01:044186-[INFO]:-gpbackup version = 1.20.220210223:16:19:19 gprestore:gpadmin:gptest01:044186-[INFO]:-gprestore version = 1.20.220210223:16:19:19 gprestore:gpadmin:gptest01:044186-[INFO]:-Greenplum Database Version = 6.2.1 build commit:d90ac1a1b983b913b3950430d4d9e47ee8827fd420210223:16:19:19 gprestore:gpadmin:gptest01:044186-[INFO]:-Creating database20210223:16:19:21 gprestore:gpadmin:gptest01:044186-[INFO]:-Database creation complete for: qmsprd20210223:16:19:21 gprestore:gpadmin:gptest01:044186-[INFO]:-Restoring pre-data metadataPre-data objects restored: 338 / 338 [================================================] 100.00% 19s20210223:16:19:41 gprestore:gpadmin:gptest01:044186-[INFO]:-Pre-data metadata restore completeTables restored: 82 / 82 [=========================================================] 100.00% 10m24s20210223:16:30:05 gprestore:gpadmin:gptest01:044186-[INFO]:-Data restore complete20210223:16:30:05 gprestore:gpadmin:gptest01:044186-[INFO]:-Restoring post-data metadataPost-data objects restored: 69 / 158 [======================>-----------------------------] 43.67%20210223:16:32:15 gprestore:gpadmin:gptest01:044186-[CRITICAL]:-ERROR: could not create unique index "wpp_sht_info_n_1_prt_p2019_pkey" (seg3 10.50.10.170:6003 pid=44257) (SQLSTATE 23505)20210223:16:32:15 gprestore:gpadmin:gptest01:044186-[INFO]:-Found neither /usr/local/greenplum-db/./bin/gp_email_contacts.yaml nor /home/gpadmin/gp_email_contacts.yaml20210223:16:32:15 gprestore:gpadmin:gptest01:044186-[INFO]:-Email containing gprestore report /gpmaster/gp/master/gpseg-1/backups/20210223/20210223153120/gprestore_20210223153120_20210223161919_report will not be sentgpbackup 提供了多个参数，可以使用 --help查看.
如果只需要备份表结构，则可以使用--metadata
~]$gpbackup --dbname qmsprd --metadata-only20210223:16:29:34 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Starting backup of database qmsprd20210223:16:29:35 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Backup Timestamp = 2021022316293420210223:16:29:35 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Backup Database = qmsprd20210223:16:29:35 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Gathering list of tables for backup20210223:16:29:43 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Acquiring ACCESS SHARE locks on tablesLocks acquired: 1525 / 1525 [=========================================================] 100.00% 11s20210223:16:29:54 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Gathering additional table metadata20210223:16:31:19 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Metadata will be written to /gpmaster/gpseg-1/backups/20210223/20210223162934/gpbackup_20210223162934_metadata.sql20210223:16:31:19 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Writing global database metadata20210223:16:31:20 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Global database metadata backup complete20210223:16:31:20 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Writing pre-data metadata20210223:16:33:32 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Pre-data metadata backup complete20210223:16:33:32 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Writing post-data metadata20210223:16:33:55 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Post-data metadata backup complete20210223:16:40:53 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Found neither /opt/greenplum/greenplum-db/./bin/gp_email_contacts.yaml nor /home/gpadmin/gp_email_contacts.yaml20210223:16:40:53 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Email containing gpbackup report /gpmaster/gpseg-1/backups/20210223/20210223162934/gpbackup_20210223162934_report will not be sent20210223:16:40:53 gpbackup:gpadmin:P1QMSMDW01:028718-[INFO]:-Backup completed successfully试想一下？如果两个集群的规模不一致，那gpbackup / gprestore还能用吗？
答案是否定的.会有如下报错
backups]$ gprestore --timestamp 20210223162934 --metadata-only --create-db 20210223:17:10:27 gprestore:gpadmin:gpmaster:013990-[INFO]:-Restore Key = 2021022316293420210223:17:10:28 gprestore:gpadmin:gpmaster:013990-[CRITICAL]:-Backup directories missing or inaccessible on 6 segments. See /home/gpadmin/gpAdminLogs/gprestore_20210223.log for a complete list of errors.20210223:17:10:28 gprestore:gpadmin:gpmaster:013990-[INFO]:-Found neither /usr/local/greenplum-db/./bin/gp_email_contacts.yaml nor /home/gpadmin/gp_email_contacts.yaml20210223:17:10:28 gprestore:gpadmin:gpmaster:013990-[INFO]:-Email containing gprestore report /greenplum/gpdata/master/gpseg-1/backups/20210223/20210223162934/gprestore_20210223162934_20210223171027_report will not be sent但是既然生成metadata的sql已经存在了。那么可以使用 psql来重放sql来实现。例如
psql -af test.sql > import_metadata.log 2>&1 -a, --echo-all echo all input from script
-f, --file=FILENAME execute commands from file, then exit
因为psql 的输出都是标准输出，因此可以将其重定向到log中。
2>&1 代表的是将标准错误输出和标准输出合并 输入到import_metadata.log
二、gpcopy
实际业务场景如下
升级：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互斥。
gpcopy实战操作