高效的并行数据库备份和恢复工具

目录

一、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互斥。