回复
添加资源
添加资源将有机会获得更多曝光，你也可以直接关联已上传资源
去关联
【干货】Greenplum备份恢复工具gpbackup（中篇）
delphi6fans
发布于 2022-5-20 18:17
浏览
0收藏
在《Greenplum备份恢复工具gpbackup》系列文章的上篇中，我们简单介绍了gpbackup，并进行了源码编译。在今天的《中篇》中，我们将介绍gpbackup 所有参数的详细使用方法。
本篇文章将参考以下内容进行操作：
- GPDB6.20DDocs - 官方英文文档的gpbackup 部分；
- gpbackup 命令帮助信息
注意：gpbackup 和 gprestore 命令只需要放置到 master 节点的 greenplum-db/bin 目录下，gpbackup_helper 命令需要放置到所有 segment host 节点的 greenplum-db/bin 目录下。
1 gpbackup备份参数详解
首先我们通过命令行来看一下gpbackup命令自带的帮助信息有哪些参数，具体含义就直接在参数后面进行翻译了哈：
[chris@gpt1 ~]$ gpbackup --help
gpbackup is the parallel backup utility for Greenplum
Usage:
gpbackup [flags]
Flags:
--backup-dir string `可选参数`, 写入备份文件的绝对路径，不能采用相对路径，如果您指定了该路径，备份操作会将所有备份文件（包括元数据文件）都放到这个目录下。如果您不指定这个选项，元数据文件会保存到Master节点的 `$MASTER_DATA_DIRECTORY/backups/YYYYMMDD/YYYYMMDDhhmmss/` 目录下，数据文件会存放在segment主机的 `<seg_dir>/backups/YYYYMMDD/ YYYYMMDDhhmmss/`目录下。该选项不能与 `--plugin-config` 选项共同使用。
--compression-level int `可选参数`, 压缩级别。大家需要注意，在当前随GPDB版本发布的gpbackup包中，只支持gzip压缩格式，如果您自行编译gpbackup，可以看到已经增加了 `compression-type` 类型，该类型支持其他的压缩类型。压缩级别的默认值为1，gpbackup在备份时，会默认启用gzip压缩。
--compression-type string `可选参数`, 压缩类型。有效值有 'gzip','zstd'，默认为 'gzip'，如果要使用 'zstd' 压缩，需要在所有服务器上安装该压缩类型以保证shell可以执行 `zstd` 命令，安装方式参考：https://github.com/facebook/zstd 。
--copy-queue-size int `可选参数`, 自行编译最新版本gpbackup带有的参数，该参数只能配合 `--single-data-file` 参数一起使用，当定义了 `--single-data-file` 参数以后，通过执行 `--copy-queue-size` 参数的值来指定gpbackup命令使用COPY命令的个数，默认值为1。
--data-only `可选参数`, 只备份数据，不备份元数据。
--dbname string `必选参数`, 只要进行备份的数据库名称，必须指定，否则会报错，备份无法进行。
--debug `可选参数`, 显示备份过程中详细的debug信息，通常用在排错场景。
--exclude-schema stringArray `可选参数`, 指定备份操作要排除的数据库模式(schema)， 如果要排除多个模式，需要多次定义，不支持 `--exclude-schema=schema1,schema2` 的方式。另外该参数与 '--exclude-schema-file, exclude-table, --exclude-table-file, --include-schema, --include-schema-file, --include-table, --include-table-file' 这几个参数不能同时使用。
--exclude-schema-file string `可选参数`, 包含备份操作要排除的数据库模式的文件，每一行为一个模式名，该文件不能包含多余的符号，如果数据库中的模式包含除了：字母、数字和下划线以外的特殊符号，那么请在文件中用双引号进行包裹。该参数与 '--exclude-schema, --exclude-table, --exclude-table-file, --include-schema, --include-schema-file, --include-table, --include-table-file' 这几个参数不能同时使用。
--exclude-table stringArray `可选参数`, 指定备份操作中要排除的表名，该参数与 '--exclude-schema, --exclude-schema-file, --exclude-table-file, --include-schema, --include-schema-file, --include-table, --include-table-file' 这几个参数不能同时使用。指定表名时，必须使用 `<schema-name>.<table-name>` 的格式指定匹配到具体的模式，如果数据库中的模式包含除了：字母、数字和下划线以外的特殊符号，那么请在文件中用双引号进行包裹。另外该参数也支持多次指定。
--exclude-table-file string `可选参数`, 指定文件包含备份操作中要排除的表名，该参数与 '--exclude-schema, --exclude-schema-file, --exclude-table, --include-schema, --include-schema-file, --include-table, --include-table-file' 这几个参数不能同时使用。指定表名时，必须使用 `<schema-name>.<table-name>` 的格式指定匹配到具体的模式，如果数据库中的模式包含除了：字母、数字和下划线以外的特殊符号，那么请在文件中用双引号进行包裹。如果有多个表，需要在文件中分行多次指定。
--from-timestamp string `可选参数`, 指定增量备份的时间戳。被指定的备份必须有增量备份集，如果没有，备份操作会自动创建一个增量备份集；如果被指定的备份是一个增量备份，则备份操作会向备份集增加一个备份。使用该参数时，必须指定参数 `--leaf-partition-data`, 并且不能与`--data-only或--metadata-only`参数一起使用。如果没有任何全量备份存在，则会报错退出备份过程。
--help 显示命令行参数帮助信息。
--include-schema stringArray `可选参数`, 指定备份操作要包含的数据库模式(schema)， 如果要包含多个模式，需要多次定义，不支持 `--include-schema=schema1,schema2` 的方式。另外该参数与 '--exclude-schema, --exclude-schema-file, exclude-table, --exclude-table-file, --include-schema-file, --include-table, --include-table-file' 这几个参数不能同时使用。
--include-schema-file string `可选参数`, 包含备份操作要包含的数据库模式的文件，每一行为一个模式名，该文件不能包含多余的符号，如果数据库中的模式包含除了：字母、数字和下划线以外的特殊符号，那么请在文件中用双引号进行包裹。该参数与 '--exclude-schema, --exclude-schema-file, --exclude-table, --exclude-table-file, --include-schema, --include-table, --include-table-file' 这几个参数不能同时使用。
--include-table stringArray `可选参数`, 指定备份操作中要包含的表名，该参数与 '--exclude-schema, --exclude-schema-file, --exclude-table, --exclude-table-file, --include-schema, --include-schema-file, --include-table-file' 这几个参数不能同时使用。指定表名时，必须使用 `<schema-name>.<table-name>` 的格式指定匹配到具体的模式，如果数据库中的模式包含除了：字母、数字和下划线以外的特殊符号，那么请在文件中用双引号进行包裹。另外该参数也支持多次指定。
--include-table-file string `可选参数`, 指定文件包含备份操作中要包含的表名，该参数与 '--exclude-schema, --exclude-schema-file, --exclude-table, --exclude-table-file, --include-schema, --include-schema-file, --include-table' 这几个参数不能同时使用。指定表名时，必须使用 `<schema-name>.<table-name>` 的格式指定匹配到具体的模式，如果数据库中的模式包含除了：字母、数字和下划线以外的特殊符号，那么请在文件中用双引号进行包裹。如果有多个表，需要在文件中分行多次指定。
--incremental `可选参数`, 增量备份功能，增量备份只支持AO表的增量，Heap表不支持增量备份。指定该选项后，会在备份集合中继续增加增量备份。在GPDB里面，备份可以全部都由全量备份构成，也可以由全量备份+增量备份的方式构成，增量备份必须与前面的全量备份组成一个连续的集合，否则无法进行恢复。如果已经做了一个全量备份但是没有增量备份，那该参数会在备份时创建一个增量备份集；如果全量和增量都已经存在了，那么该参数会在现有增量备份集中增加一个最新的备份；另外也可以通过指定 '--from-timestamp' 参数来改变默认行为。
--jobs int `可选参数`, 指定进行表备份过程中的并行任务数，如果不指定，该值默认为1，gpbackup会使用一个任务（即一个数据库连接）进行备份。可以通过增加该值来提升备份速度，如果指定了大于1的值，备份操作会以表为单位进行并发操作，每个表开启一个单独的事务。需要特别注意的是，指定该参数进行并发备份时，不要进行外部程序操作，否则无法保证多表之间的事物一致性。该参数可以与 `--metadata-only, -- single-data-file, --plugin-config` 参数共同使用。
--leaf-partition-data `可选参数`, 为分区表的每一个叶子节点单独创建备份文件，而不是为整个表创建一个备份文件(默认)。使用该参数配合 `--include-table, -- include-table-file, --exclude-table, --exclude-table-file` 参数可以实现包含或排除叶子节点数据的操作。
--metadata-only `可选参数`, 仅备份元数据（即创建数据库对象的DDL语句），不备份任何实际的生产表数据。
--no-compression `可选参数`, 不启用压缩。
--plugin-config string `可选参数`, 指定plugin配置文件位置，该文件是一个有效的YAML文件，用来指定在备份过程中使用的plugin应用的配置信息。由于备份的plugin通常都是为了将备份放到远程存储，所以该选项不能与 `--backup-dir` 同时使用；例如可以使用s3的库将备份文件放到亚马逊S3存储上。也可以通过开放接口自己编写plugin，具体可以参考：https://gpdb.docs.pivotal.io/6-17/admin_guide/managing/backup-plugins.html
--quiet `可选参数`, 静默模式，除了warning和error信息都不打印。
--single-data-file `可选参数`, 每个segment的数据备份成一个未见，而不是每个表备份一个文件（默认）。如果指定了该选项，在使用gprestore恢复的时候，不能使用 `--job` 选项进行并发恢复。需要特别注意，如果要使用该参数，需要配合 `gpbackup_helper` 命令一起使用，该命令与gpbackup和gpresotre一起编译生成，需要把这个命令放到所有segment host的greenplum-db/bin目录下。
--verbose `可选参数`, 打印详细日志信息。
--version 打印gpbackup的版本号并退出。
--with-stats `可选参数`, 备份查询计划统计信息。
--without-globals `可选参数`, 不备份全局对象。
从上面各个参数的详细解释中，大家也可以得出一个总结，gpbackup 的必选参数只有 --dbname，其他参数均为可选参数，有些参数之间是存在互斥关系的，大家在使用过程中一定要注意。
2 gpbackup备份实验及总结
在上面一部分，进行了详细的参数解释，下面我们通过一系列的实验来对一些特别的参数和场景进行演示。因为参数过多，不能一一列举，所以尽可能选用一些大家常用的场景，场景之间可能存在顺序关联关系，还请各位依次阅读。
2.1 常规备份，只指定--dbname参数
通过该试验让大家认识gpbackup备份操作生成的各类文件的内容及作用，方便大家对备份有一个整体的了解。
实验语句：
[chris@gpt1 ~]$ gpbackup --dbname=db3
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-gpbackup version = 1.23.0+dev.6.gabcfe15
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Greenplum Database Version = 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aed
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Starting backup of database db3
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Backup Timestamp = 20220401174346
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Backup Database = db3
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Gathering table state information
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Acquiring ACCESS SHARE locks on tables
Locks acquired: 2 / 2 [================================================================] 100.00% 0s
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Gathering additional table metadata
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Getting partition definitions
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Getting storage information
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Getting child partitions with altered schema
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Metadata will be written to /data/master/gp-1/backups/20220401/20220401174346/gpbackup_20220401174346_metadata.sql
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Writing global database metadata
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Global database metadata backup complete
20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Writing pre-data metadata
20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Pre-data metadata metadata backup complete
20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Writing post-data metadata
20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Post-data metadata backup complete
20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Writing data to file
Tables backed up: 2 / 2 [==============================================================] 100.00% 0s
20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Data backup complete
20220401:17:43:48 gpbackup:chris:gpt1:004385-[INFO]:-Found neither /usr/local/greenplum-db-6.15.0/bin/gp_email_contacts.yaml nor /home/chris/gp_email_contacts.yaml
20220401:17:43:48 gpbackup:chris:gpt1:004385-[INFO]:-Email containing gpbackup report /data/master/gp-1/backups/20220401/20220401174346/gpbackup_20220401174346_report will not be sent
20220401:17:43:48 gpbackup:chris:gpt1:004385-[INFO]:-Backup completed successfully实验总结：
如果只指定数据库名称，会将这个数据库的所有对象都进行备份，例如：元数据、表数据、资源队列、资源组、角色等。
元数据存储在Master节点的
$MASTER_DATA_DIRECTORY/backups/YYYYMMDD/YYYYMMDDhhmmss/
目录下，会生成4个文件，其中：config.yaml 记录gpbackup 运行时的参数配置项；report记录备份下来的数据库对象信息，主要是对象数量；toc.yaml 记录元数据之间的依赖关系；metadata.sql 记录表结构DDL的详细信息。
Master节点生成的四个文件：
[chris@gpt1 20220401174346]$ ll
总用量 16
-r--r--r--. 1 chris chris 725 4月 1 17:43 gpbackup_20220401174346_config.yaml
-r--r--r--. 1 chris chris 2313 4月 1 17:43 gpbackup_20220401174346_metadata.sql
-r--r--r--. 1 chris chris 1786 4月 1 17:43 gpbackup_20220401174346_report
-r--r--r--. 1 chris chris 4070 4月 1 17:43 gpbackup_20220401174346_toc.yamlconfig.yaml文件内容展示：
[chris@gpt1 20220401174346]$ cat gpbackup_20220401174346_config.yaml
backupdir: ""
backupversion: 1.23.0+dev.6.gabcfe15
compressed: true
compressiontype: gzip
databasename: db3
databaseversion: 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aed
dataonly: false
datedeleted: ""
excluderelations: []
excludeschemafiltered: false
excludeschemas: []
excludetablefiltered: false
includerelations: []
includeschemafiltered: false
includeschemas: []
includetablefiltered: false
incremental: false
leafpartitiondata: false
metadataonly: false
plugin: ""
pluginversion: ""
restoreplan:
- timestamp: "20220401174346"
tablefqns:
- public.t1
- public.t2
singledatafile: false
timestamp: "20220401174346"
endtime: "20220401174348"
withoutglobals: false
withstatistics: false
status: Success
report文件内容展示：
[chris@gpt1 20220401174346]$ cat gpbackup_20220401174346_report
Greenplum Database Backup Report
timestamp key: 20220401174346
gpdb version: 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aed
gpbackup version: 1.23.0+dev.6.gabcfe15
database name: db3
command line: gpbackup --dbname=db3
compression: gzip
plugin executable: None
backup section: All Sections
object filtering: None
includes statistics: No
data file format: Multiple Data Files Per Segment
incremental: False
start time: Fri Apr 01 2022 17:43:46
end time: Fri Apr 01 2022 17:43:48
duration: 0:00:02
backup status: Success
database size: 83 MB
count of database objects in backup:
aggregates 0
casts 0
collations 0
constraints 0
conversions 0
default privileges 0
database gucs 0
event triggers 0
extensions 0
foreign data wrappers 0
foreign servers 0
functions 0
indexes 0
operator classes 0
operator families 0
operators 0
procedural languages 0
protocols 0
resource groups 3
resource queues 2
roles 2
rules 0
schemas 3
sequences 0
tables 2
tablespaces 0
text search configurations 0
text search dictionaries 0
text search parsers 0
text search templates 0
triggers 0
types 0
user mappings 0
views 0
toc.yaml文件内容展示(内容太长，节选部分)：
[chris@gpt1 20220401174346]$ cat gpbackup_20220401174346_toc.yaml
globalentries:
- schema: ""
name: ""
objecttype: SESSION GUCS
referenceobject: ""
startbyte: 0
endbyte: 31
- schema: ""
name: pg_default
objecttype: RESOURCE QUEUE
referenceobject: ""
startbyte: 31
endbyte: 93
- schema: ""
name: rs1
objecttype: RESOURCE QUEUE
referenceobject: ""
startbyte: 93
endbyte: 172
- schema: ""
name: db3
objecttype: DATABASE METADATA
referenceobject: ""
startbyte: 1701
endbyte: 1740
predataentries:
- schema: public
name: public
objecttype: SCHEMA
referenceobject: ""
startbyte: 1740
endbyte: 1741
- schema: public
name: t1
objecttype: TABLE
referenceobject: ""
startbyte: 2167
endbyte: 2209
postdataentries: []
statisticsentries: []
dataentries:
- schema: public
name: t1
oid: 16387
attributestring: (id)
rowscopied: 100
partitionroot: ""
incrementalmetadata:
ao: {}
metadata.sql文件内容展示(内容太长，节选部分)：
SET client_encoding = 'UTF8';
ALTER RESOURCE QUEUE pg_default WITH (ACTIVE_STATEMENTS=20);
CREATE RESOURCE QUEUE rs1 WITH (ACTIVE_STATEMENTS=10, MAX_COST=400000000.00);
ALTER RESOURCE GROUP admin_group SET CPU_RATE_LIMIT 1;
ALTER RESOURCE GROUP admin_group SET MEMORY_LIMIT 1;
ALTER RESOURCE GROUP default_group SET CPU_RATE_LIMIT 1;
ALTER RESOURCE GROUP default_group SET MEMORY_LIMIT 1;
ALTER RESOURCE GROUP default_group SET MEMORY_LIMIT 0;
ALTER RESOURCE GROUP default_group SET MEMORY_SHARED_QUOTA 80;
ALTER RESOURCE GROUP default_group SET MEMORY_SPILL_RATIO 0;
ALTER RESOURCE GROUP default_group SET CONCURRENCY 20;
ALTER RESOURCE GROUP default_group SET CPU_RATE_LIMIT 30;
ALTER RESOURCE GROUP admin_group SET MEMORY_LIMIT 10;
ALTER RESOURCE GROUP admin_group SET MEMORY_SHARED_QUOTA 80;
ALTER RESOURCE GROUP admin_group SET MEMORY_SPILL_RATIO 0;
ALTER RESOURCE GROUP admin_group SET CONCURRENCY 10;
ALTER RESOURCE GROUP admin_group SET CPU_RATE_LIMIT 10;
CREATE RESOURCE GROUP rs2 WITH (CPU_RATE_LIMIT=1, MEMORY_AUDITOR=vmtracker, MEMORY_LIMIT=0, MEMORY_SHARED_QUOTA=80, MEMORY_SPILL_RATIO=0, CONCURRENCY=200);
CREATE ROLE chris;
ALTER ROLE chris WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN REPLICATION PASSWORD 'md5757e3ad047f2a6e55fdd6ce7b66dcba5' RESOURCE QUEUE pg_default RESOURCE GROUP admin_group CREATEEXTTABLE (protocol='http') CREATEEXTTABLE (protocol='gpfdist', type='readable') CREATEEXTTABLE (protocol='gpfdist', type='writable');
CREATE ROLE dbuser3;
ALTER ROLE dbuser3 WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB LOGIN PASSWORD 'md5549ea76731c7b2f80ca2971c74ac2c3c' RESOURCE QUEUE rs1 RESOURCE GROUP rs2;
...
...
生产表数据存储在segment实例的backups目录下，比如我这边：
/data/primary/gp1/backups/20220401/20220401182945，
默认情况下，每个表生成一个单独的gzip压缩文件，通过pg_class中的oid作为后缀来做表关联对应。segment节点不存储任何生产表数据之外的数据。
数据库中2个测试表的文件如下：
[chris@gpt2 20220401182945]$ ll
总用量 8
-rw-------. 1 chris chris 73 4月 1 18:29 gpbackup_1_20220401182945_16387.gz
-rw-------. 1 chris chris 109 4月 1 18:29 gpbackup_1_20220401182945_16403.gz
解压打开其中一个表文件看一下，里面是csv内容：
1,1name
12,12name
15,15name
20,20name
23,23name
有关这些文件的更详细含义，请参考文章：
https://greenplum.docs.pivotal.io/backup-restore/1-24/admin_guide/managing/backup-gpbackup.html#topic_qwd_d5d_tbb
2.2 指定--backup-dir参数进行备份
实验语句：
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/
日志省略～实验总结：
指定--backup-dir的操作可以将备份统一到一个固定的目录，这就要求所有服务器上必须都存在--backup-dir后面指定的这个目录，比如我这里的目录是/data/backups/。这个适合公司对备份目录有固定要求，或者必须放置到共享存储中的场景，通过定义统一的目录，就可以把所有的备份数据都放在我们可以获知的任意位置（当然管理员用户必须具有目录的访问权限）。
Master节点上的信息展示如下，文件还是那些文件，只不过目录不同了。
[chris@gpt1 20220401184922]$ ll
总用量 16
-r--r--r--. 1 chris chris 737 4月 1 18:49 gpbackup_20220401184922_config.yaml
-r--r--r--. 1 chris chris 2325 4月 1 18:49 gpbackup_20220401184922_metadata.sql
-r--r--r--. 1 chris chris 1814 4月 1 18:49 gpbackup_20220401184922_report
-r--r--r--. 1 chris chris 4075 4月 1 18:49 gpbackup_20220401184922_toc.yaml
Segment节点上的信息展示如下，可以看到是通过segment名字进行区别，所以不要担心在共享存储中会出现覆盖的问题。
[chris@gpt2 20220401184922]$ pwd
/data/backups/gp0/backups/20220401/20220401184922
[chris@gpt2 20220401184922]$ ll
总用量 8
-rw-------. 1 chris chris 115 4月 1 18:49 gpbackup_0_20220401184922_16403.gz
-rw-------. 1 chris chris 138 4月 1 18:49 gpbackup_0_20220401184922_16409.gz
2.3 指定--data-only参数只备份数据
实验语句：
[chris@gpt1 20220401184922]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --data-only
日志省略～实验总结：
如果指定了--data-only，Master节点将不会导出创建数据库对象的DDL语句，这个场景只适合于数据临时导出操作，没有表结构，如果恢复的时候数据库中没有表，也无法实现恢复。个人感觉这种场景不太多，毕竟备份一下DDL也不浪费多少时间。
Master节点中查看metadata.sql文件，没有信息：
[chris@gpt1 20220401185833]$ pwd
/data/backups/gp-1/backups/20220401/20220401185833
[chris@gpt1 20220401185833]$ ll
总用量 16
-r--r--r--. 1 chris chris 736 4月 1 18:58 gpbackup_20220401185833_config.yaml
-r--r--r--. 1 chris chris 31 4月 1 18:58 gpbackup_20220401185833_metadata.sql
-r--r--r--. 1 chris chris 780 4月 1 18:58 gpbackup_20220401185833_report
-r--r--r--. 1 chris chris 432 4月 1 18:58 gpbackup_20220401185833_toc.yaml
[chris@gpt1 20220401185833]$ cat gpbackup_20220401185833_metadata.sql
SET client_encoding = 'UTF8';
[chris@gpt1 20220401185833]$
Segment节点，显然只有表数据：
[chris@gpt2 20220401185833]$ pwd
/data/backups/gp0/backups/20220401/20220401185833
[chris@gpt2 20220401185833]$ ll
总用量 8
-rw-------. 1 chris chris 115 4月 1 18:58 gpbackup_0_20220401185833_16403.gz
-rw-------. 1 chris chris 138 4月 1 18:58 gpbackup_0_20220401185833_16409.gz
2.4 指定--jobs参数进行并行备份
实验语句：
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --jobs=2
我这里数据库中只创建了2个表，所以我直接用了2个并发，返回的日志与之前并没什么区别，忽略。实验总结：
指定了--jobs=2参数以后，理论上在各个节点上备份时，会同时启动两个事务分别备份2个表，我们可以通过数据库的日志进行甄别，如下可以看到，四条日志中，前两条是上一次备份的日志，没开并行，可以看出时间是顺序的；后两条是本次开启2个并行的备份操作，可以看到基本是同一时间发起的：
2022-04-01 18:49:22.440657 CST,"chris","db3",p23834,th397211776,"10.211.55.65","57566",2022-04-01 18:49:22 CST,0,con119,cmd5,seg0,,dx48,,sx1,"LOG","00000","serializable isolation requested, falling back to repeatable read until serializable is supported in Greenplum",,,,,,"SET transaction_isolation TO 'serializable'",0,,"variable.c",604,
2022-04-01 18:58:33.484600 CST,"chris","db3",p25688,th397211776,"10.211.55.65","57660",2022-04-01 18:58:33 CST,0,con122,cmd5,seg0,,dx49,,sx1,"LOG","00000","serializable isolation requested, falling back to repeatable read until serializable is supported in Greenplum",,,,,,"SET transaction_isolation TO 'serializable'",0,,"variable.c",604,
2022-04-01 19:11:01.668405 CST,"chris","db3",p28223,th397211776,"10.211.55.65","57788",2022-04-01 19:11:01 CST,0,con127,cmd5,seg0,,dx50,,sx1,"LOG","00000","serializable isolation requested, falling back to repeatable read until serializable is supported in Greenplum",,,,,,"SET transaction_isolation TO 'serializable'",0,,"variable.c",604,
2022-04-01 19:11:01.680513 CST,"chris","db3",p28227,th397211776,"10.211.55.65","57796",2022-04-01 19:11:01 CST,0,con128,cmd4,seg0,,dx51,,sx1,"LOG","00000","serializable isolation requested, falling back to repeatable read until serializable is supported in Greenplum",,,,,,"SET transaction_isolation TO 'serializable'",0,,"variable.c",604,
2.5 指定--single-data-file参数将segment数据备份成单个文件
实验语句：
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --jobs=2 --single-data-file
20220401:20:40:04 gpbackup:chris:gpt1:006190-[CRITICAL]:-The following flags may not be specified together: jobs, metadata-only, single-data-file
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --single-data-file实验总结：
在上面的实验中，我首先把--jobs=2和--single-data-file参数同时使用，大家可以发现已经出现报错了，因为不支持这两个参数同时使用。下面第二个命令将并发参数去掉后，可以正常备份，这个参数会影响到segment节点把所有的表数据都备份到同一个文件中，如下查看单个segment备份目录下的文件可以看出：
[chris@gpt2 20220401204015]$ pwd
/data/backups/gp1/backups/20220401/20220401204015
[chris@gpt2 20220401204015]$ ll
总用量 8
-rw-rw-r--. 1 chris chris 247 4月 1 20:40 gpbackup_1_20220401204015.gz
-r--r--r--. 1 chris chris 101 4月 1 20:40 gpbackup_1_20220401204015_toc.yaml
2.6 指定--incremental参数进行增量备份
增量备份只对AO表起作用，下面我们构造一下这个场景。
实验语句：
创建AO表，并插入四条数据：
[chris@gpt1 ~]$ psql -d db3 -U dbuser3 -h 127.0.0.1 -W
Password for user dbuser3:
psql (9.4.24)
Type "help" for help.
db3=> create table tao(id int) with (appendoptimized=true);
NOTICE: Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'id' as the Greenplum Database data distribution key for this table.
HINT: The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.
CREATE TABLE
db3=> insert into tao values(1),(2),(3),(4);
INSERT 0 4
db3=>尝试带--incremental参数备份，可以预见到会报错两次，一次是因为没有同时指定--incremental和--leaf-partition-data参数；指定后，二次报错是没发现之前的全量备份版本，会报错推出：
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --incremental
20220401:20:50:04 gpbackup:chris:gpt1:008159-[CRITICAL]:---leaf-partition-data must be specified with --incremental
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --incremental --leaf-partition-data
20220401:20:50:20 gpbackup:chris:gpt1:008213-[INFO]:-gpbackup version = 1.23.0+dev.6.gabcfe15
20220401:20:50:20 gpbackup:chris:gpt1:008213-[INFO]:-Greenplum Database Version = 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aed
20220401:20:50:20 gpbackup:chris:gpt1:008213-[INFO]:-Starting backup of database db3
20220401:20:50:21 gpbackup:chris:gpt1:008213-[INFO]:-Backup Timestamp = 20220401205020
20220401:20:50:21 gpbackup:chris:gpt1:008213-[INFO]:-Backup Database = db3
20220401:20:50:21 gpbackup:chris:gpt1:008213-[CRITICAL]:-There was no matching previous backup found with the flags provided. Please take a full backup.
20220401:20:50:22 gpbackup:chris:gpt1:008213-[INFO]:-Found neither /usr/local/greenplum-db-6.15.0/bin/gp_email_contacts.yaml nor /home/chris/gp_email_contacts.yaml
20220401:20:50:22 gpbackup:chris:gpt1:008213-[INFO]:-Email containing gpbackup report /data/backups/gp-1/backups/20220401/20220401205020/gpbackup_20220401205020_report will not be sent
重新备份，先执行全量备份，再执行增量备份，此处需要注意，增量备份所使用的基础备份，必须也带有--leaf-partition-data参数，否则仍然会报错：
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --leaf-partition-data
日志省略～
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --leaf-partition-data --incremental
日志省略～大家可以从下面的日志中看出，首先我先查看了一下所有的备份，其中最后两个文件夹，一个是base基础备份，另一个是增量备份文件夹，如果再次做增量备份，会生成一个基于上一次增量的新文件夹；然后我看了一下base基础备份里面，有3个文件，分别代表两个heap表t1/t2和ao表tao；接下来，我又进入了增量文件夹中，看到了只有两个文件，因为ao表没有做数据增加所以没有新的备份；我解压了其中的heap表，看到文件的数据是全量的。在下面的一个代码演示中，我会新增ao表的数据，咱们再看一看。
[chris@gpt2 20220401]$ ls
20220401184922 20220401191101 20220401205020 20220401205440 20220401205603 20220401205649 20220401210014 20220401210414
20220401185833 20220401204015 20220401205430 20220401205529 20220401205627 20220401205745 20220401210405
[chris@gpt2 20220401210405]$ ls
gpbackup_1_20220401210405_16403.gz gpbackup_1_20220401210405_16409.gz gpbackup_1_20220401210405_16415.gz
[chris@gpt2 20220401210405]$ cd ..
[chris@gpt2 20220401]$ cd 20220401210414
[chris@gpt2 20220401210414]$ ls
gpbackup_1_20220401210414_16403.gz gpbackup_1_20220401210414_16409.gz
[chris@gpt2 20220401210414]$ gunzip gpbackup_1_20220401210414_16403.gz
[chris@gpt2 20220401210414]$ ls
gpbackup_1_20220401210414_16403 gpbackup_1_20220401210414_16409.gz
[chris@gpt2 20220401210414]$ cat gpbackup_1_20220401210414_16403
1
12
15
20
23
35
38
40
44
47
部分省略新增AO表数据（原来有4条数据，每个seg上应该有1条，再新增4条）看看是什么情况：
首先我们在segment host上查看一下之前备份的base基础数据，ao表中只有1条数据：
[chris@gpt2 20220401]$ cd 20220401210405
[chris@gpt2 20220401210405]$ ls
gpbackup_1_20220401210405_16403.gz gpbackup_1_20220401210405_16409.gz gpbackup_1_20220401210405_16415.gz
[chris@gpt2 20220401210405]$ gunzip gpbackup_1_20220401210405_16415.gz
[chris@gpt2 20220401210405]$ ls
gpbackup_1_20220401210405_16403.gz gpbackup_1_20220401210405_16409.gz gpbackup_1_20220401210405_16415
[chris@gpt2 20220401210405]$ cat gpbackup_1_20220401210405_16415
1我们新增4条数据，再次备份，并查看增量备份的数据：
[chris@gpt1 ~]$ psql -d db3 -U dbuser3 -h 127.0.0.1 -W
Password for user dbuser3:
psql (9.4.24)
Type "help" for help.
db3=> insert into tao values(5),(6),(7),(8);
INSERT 0 4
db3=> \q
[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --leaf-partition-data --incremental
下面切换回segment host查看
[chris@gpt3 20220401]$ ls
20220401184922 20220401191101 20220401205020 20220401205440 20220401205603 20220401205649 20220401210014 20220401210414 20220401211608
20220401185833 20220401204015 20220401205430 20220401205529 20220401205627 20220401205745 20220401210405 20220401210816
[chris@gpt3 20220401]$ cd 20220401211608
[chris@gpt3 20220401211608]$ ls
gpbackup_2_20220401211608_16403.gz gpbackup_2_20220401211608_16409.gz gpbackup_2_20220401211608_16415.gz
[chris@gpt3 20220401211608]$ gunzip gpbackup_2_20220401211608_16415.gz
[chris@gpt3 20220401211608]$ cat gpbackup_2_20220401211608_16415
5实验总结：
增量备份参数--incremental，需要与--leaf-partition-data参数同时使用，并且在创建基础全量备份时，也必须带有该参数，否则增量备份找不到基础备份会报错退出。另外增量备份只对AO表有效，Heap表每次都会进行全量备份。
3 总 结
至此，本次 gpbackup 主题的中篇 - 备份参数详解就到此演示结束了，其中还有很多参数没有一一进行演示，大家可以自行安装操作进行尝鲜，文章中代码和日志演示较多，感谢大家耐心看到最后。
在将于下周推送的《下篇》中，我们会对 gprestore 进行演示并介绍一些其他的功能。欢迎大家关注！
作者简介
苑泽福，Greenplum中文社区专家
曾供职于鼎兴达、瀚高，拥有丰富的数据库开发运维经验，近年来一直专注于Greenplum 数据库，完成了多个基于Greenplum的数据平台的落地
文章转自公众号：Greenplum中文社区
分类
标签
已于2022-5-20 18:17:42修改
赞
收藏
回复
举报
相关推荐
