【干货】Greenplum备份恢复工具gpbackup（中篇）

 

在《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.yaml

config.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中文社区