【干货】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.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中文社区

分类
标签
已于2022-5-20 18:17:42修改
收藏
回复
举报
回复
    相关推荐