【干货】Greenplum备份恢复工具gpbackup(中篇)

61e4a8f2-561d-4b2f-a96d-e60f55722440.jpg


在《Greenplum备份恢复工具gpbackup》系列文章的 上篇中 ,我们简单介绍了gpbackup,并进行了源码编译。在今天的《中篇》中,我们将介绍gpbackup 所有参数的详细使用方法。



本篇文章将参考以下内容进行操作:


  • GPDB6.20DDocs - 官方英文文档的gpbackup 部分;

  • gpbackup 命令帮助信息


注意: gpbackup 和 gprestore 命令只需要放置到 master 节点的 greenplum-db/bin 目录下,gpbackup_helper 命令需要放置到所有 segment host 节点的 greenplum-db/bin 目录下。


1

gpbackup备份参数详解

0d4207c3-d7ea-443d-a5ed-0eb6ccd55ddb.gif


首先我们通过命令行来看一下gpbackup命令自带的帮助信息有哪些参数,具体含义就直接在参数后面进行翻译了哈:

[chris@gpt1 ~]$ gpbackup --helpgpbackup 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备份实验及总结

0d4207c3-d7ea-443d-a5ed-0eb6ccd55ddb.gif


在上面一部分,进行了详细的参数解释,下面我们通过一系列的实验来对一些特别的参数和场景进行演示。因为参数过多,不能一一列举,所以尽可能选用一些大家常用的场景,场景之间可能存在顺序关联关系,还请各位依次阅读。


425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif

2.1 常规备份,只指定--dbname参数

425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif


通过该试验让大家认识gpbackup备份操作生成的各类文件的内容及作用,方便大家对备份有一个整体的了解。


实验语句:

[chris@gpt1 ~]$ gpbackup --dbname=db320220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-gpbackup version = 1.23.0+dev.6.gabcfe1520220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Greenplum Database Version = 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aed20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Starting backup of database db320220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Backup Timestamp = 2022040117434620220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Backup Database = db320220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Gathering table state information20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Acquiring ACCESS SHARE locks on tablesLocks acquired:  2 / 2 [================================================================] 100.00% 0s20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Gathering additional table metadata20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Getting partition definitions20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Getting storage information20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Getting child partitions with altered schema20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Metadata will be written to /data/master/gp-1/backups/20220401/20220401174346/gpbackup_20220401174346_metadata.sql20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Writing global database metadata20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Global database metadata backup complete20220401:17:43:46 gpbackup:chris:gpt1:004385-[INFO]:-Writing pre-data metadata20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Pre-data metadata metadata backup complete20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Writing post-data metadata20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Post-data metadata backup complete20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Writing data to fileTables backed up:  2 / 2 [==============================================================] 100.00% 0s20220401:17:43:47 gpbackup:chris:gpt1:004385-[INFO]:-Data backup complete20220401: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.yaml20220401: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 sent20220401: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.yamlbackupdir: ""backupversion: 1.23.0+dev.6.gabcfe15compressed: truecompressiontype: gzipdatabasename: db3databaseversion: 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aeddataonly: falsedatedeleted: ""excluderelations: []excludeschemafiltered: falseexcludeschemas: []excludetablefiltered: falseincluderelations: []includeschemafiltered: falseincludeschemas: []includetablefiltered: falseincremental: falseleafpartitiondata: falsemetadataonly: falseplugin: ""pluginversion: ""restoreplan:- timestamp: "20220401174346"  tablefqns:  - public.t1  - public.t2singledatafile: falsetimestamp: "20220401174346"endtime: "20220401174348"withoutglobals: falsewithstatistics: falsestatus: Success


report文件内容展示:

[chris@gpt1 20220401174346]$ cat gpbackup_20220401174346_reportGreenplum Database Backup Report
timestamp key: 20220401174346gpdb version: 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aedgpbackup version: 1.23.0+dev.6.gabcfe15
database name: db3command line: gpbackup --dbname=db3compression: gzipplugin executable: Nonebackup section: All Sectionsobject filtering: Noneincludes statistics: Nodata file format: Multiple Data Files Per Segmentincremental: False
start time: Fri Apr 01 2022 17:43:46end time: Fri Apr 01 2022 17:43:48duration: 0:00:02
backup status: Success
database size: 83 MB
count of database objects in backup:aggregates 0casts 0collations 0constraints 0conversions 0default privileges 0database gucs 0event triggers 0extensions 0foreign data wrappers 0foreign servers 0functions 0indexes 0operator classes 0operator families 0operators 0procedural languages 0protocols 0resource groups 3resource queues 2roles 2rules 0schemas 3sequences 0tables 2tablespaces 0text search configurations 0text search dictionaries 0text search parsers 0text search templates 0triggers 0types 0user mappings 0views                        0


toc.yaml文件内容展示(内容太长,节选部分):

[chris@gpt1 20220401174346]$ cat gpbackup_20220401174346_toc.yamlglobalentries:- schema: ""name: ""objecttype: SESSION GUCSreferenceobject: ""startbyte: 0endbyte: 31- schema: ""name: pg_defaultobjecttype: RESOURCE QUEUEreferenceobject: ""startbyte: 31endbyte: 93- schema: ""name: rs1objecttype: RESOURCE QUEUEreferenceobject: ""startbyte: 93endbyte: 172- schema: ""name: db3objecttype: DATABASE METADATAreferenceobject: ""startbyte: 1701endbyte: 1740predataentries:- schema: publicname: publicobjecttype: SCHEMAreferenceobject: ""startbyte: 1740endbyte: 1741- schema: publicname: t1objecttype: TABLEreferenceobject: ""startbyte: 2167endbyte: 2209postdataentries: []statisticsentries: []dataentries:- schema: publicname: t1oid: 16387attributestring: (id)rowscopied: 100partitionroot: ""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,1name12,12name15,15name20,20name23,23name


有关这些文件的更详细含义,请参考文章:

https://greenplum.docs.pivotal.io/backup-restore/1-24/admin_guide/managing/backup-gpbackup.html#topic_qwd_d5d_tbb


425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif

2.2 指定--backup-dir参数进行备份

425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif


实验语句:

[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 41 18:49 gpbackup_0_20220401184922_16403.gz-rw-------. 1 chris chris 138 4月   1 18:49 gpbackup_0_20220401184922_16409.gz


425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif

2.3 指定--data-only参数只备份数据

425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif


实验语句:

[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 41 18:58 gpbackup_20220401185833_config.yaml-r--r--r--. 1 chris chris  31 41 18:58 gpbackup_20220401185833_metadata.sql-r--r--r--. 1 chris chris 780 41 18:58 gpbackup_20220401185833_report-r--r--r--. 1 chris chris 432 41 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 41 18:58 gpbackup_0_20220401185833_16403.gz-rw-------. 1 chris chris 138 4月   1 18:58 gpbackup_0_20220401185833_16409.gz


425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif

2.4 指定--jobs参数进行并行备份

425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif


实验语句:

[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,


425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif

2.5 指定--single-data-file参数 将segment数据备份成单个文件

425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif


实验语句:

[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --jobs=2 --single-data-file20220401: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 41 20:40 gpbackup_1_20220401204015.gz-r--r--r--. 1 chris chris 101 4月   1 20:40 gpbackup_1_20220401204015_toc.yaml


425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif

2.6 指定--incremental参数进行增量备份

425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif 425416b8-d7bc-470e-a88b-9b5ed8dcf6d8.gif


增量备份只对AO表起作用,下面我们构造一下这个场景。


实验语句:

创建AO表,并插入四条数据:

[chris@gpt1 ~]$ psql -d db3 -U dbuser3 -h 127.0.0.1 -WPassword 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 TABLEdb3=> insert into tao values(1),(2),(3),(4);INSERT 0 4db3=>


尝试带--incremental参数备份,可以预见到会报错两次,一次是因为没有同时指定--incremental和--leaf-partition-data参数;指定后,二次报错是没发现之前的全量备份版本,会报错推出:

[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --incremental20220401: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-data20220401:20:50:20 gpbackup:chris:gpt1:008213-[INFO]:-gpbackup version = 1.23.0+dev.6.gabcfe1520220401:20:50:20 gpbackup:chris:gpt1:008213-[INFO]:-Greenplum Database Version = 6.15.0 build commit:4e6288c9e9fca634b007a978fba3ce25aae26aed20220401:20:50:20 gpbackup:chris:gpt1:008213-[INFO]:-Starting backup of database db320220401:20:50:21 gpbackup:chris:gpt1:008213-[INFO]:-Backup Timestamp = 2022040120502020220401:20:50:21 gpbackup:chris:gpt1:008213-[INFO]:-Backup Database = db320220401: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.yaml20220401: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]$ ls20220401184922  20220401191101  20220401205020  20220401205440  20220401205603  20220401205649  20220401210014  2022040121041420220401185833  20220401204015  20220401205430  20220401205529  20220401205627  20220401205745  20220401210405[chris@gpt2 20220401210405]$ lsgpbackup_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]$ lsgpbackup_1_20220401210414_16403.gz  gpbackup_1_20220401210414_16409.gz[chris@gpt2 20220401210414]$ gunzip gpbackup_1_20220401210414_16403.gz[chris@gpt2 20220401210414]$ lsgpbackup_1_20220401210414_16403  gpbackup_1_20220401210414_16409.gz[chris@gpt2 20220401210414]$ cat gpbackup_1_20220401210414_164031121520233538404447部分省略


新增AO表数据(原来有4条数据,每个seg上应该有1条,再新增4条)看看是什么情况:

首先我们在segment host上查看一下之前备份的base基础数据,ao表中只有1条数据:

[chris@gpt2 20220401]$ cd 20220401210405[chris@gpt2 20220401210405]$ lsgpbackup_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]$ lsgpbackup_1_20220401210405_16403.gz  gpbackup_1_20220401210405_16409.gz  gpbackup_1_20220401210405_16415[chris@gpt2 20220401210405]$ cat gpbackup_1_20220401210405_164151


我们新增4条数据,再次备份,并查看增量备份的数据:

[chris@gpt1 ~]$ psql -d db3 -U dbuser3 -h 127.0.0.1 -WPassword for user dbuser3:psql (9.4.24)Type "help" for help.
db3=> insert into tao values(5),(6),(7),(8);INSERT 0 4db3=> \q[chris@gpt1 ~]$ gpbackup --dbname=db3 --backup-dir=/data/backups/ --leaf-partition-data --incremental下面切换回segment host查看[chris@gpt3 20220401]$ ls20220401184922 20220401191101 20220401205020 20220401205440 20220401205603 20220401205649 20220401210014 20220401210414 2022040121160820220401185833 20220401204015 20220401205430 20220401205529 20220401205627 20220401205745 20220401210405 20220401210816[chris@gpt3 20220401]$ cd 20220401211608[chris@gpt3 20220401211608]$ lsgpbackup_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_164155


实验总结:

增量备份参数--incremental,需要与--leaf-partition-data参数同时使用,并且在创建基础全量备份时,也必须带有该参数,否则增量备份找不到基础备份会报错退出。另外增量备份只对AO表有效,Heap表每次都会进行全量备份。


3

总 结

0d4207c3-d7ea-443d-a5ed-0eb6ccd55ddb.gif


至此,本次 gpbackup 主题的中篇 - 备份参数详解就到此演示结束了,其中还有很多参数没有一一进行演示,大家可以自行安装操作进行尝鲜,文章中代码和日志演示较多,感谢大家耐心看到最后。


在将于下周推送的《下篇》中,我们会对 gprestore 进行演示并介绍一些其他的功能。欢迎大家关注!



作者简介


苑泽福,Greenplum中文社区专家

曾供职于鼎兴达、瀚高,拥有丰富的数据库开发运维经验,近年来一直专注于Greenplum 数据库,完成了多个基于Greenplum的数据平台的落地



点击文末“ 阅读原文 ”,获取Greenplum中文资源。




45edf131-e1b7-4db9-8bdc-95530b401752.gif

0fbb88ca-dbf3-46e6-927c-2efa4692ae47.png 来一波 “在看”、“分享” “赞” 吧!


本文分享自微信公众号 - Greenplum中文社区(GreenplumCommunity)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“ OSC源创计划 ”,欢迎正在阅读的你也加入,一起分享。

<think>好的,用户想了解RCAB模块在图像超分辨率任务中的作用和原理。首先,我需要回忆一下RCAB的相关知识。RCAB全称是Residual Channel Attention Block,应该是在残差块的基础上加入了通道注意力机制。这通常用于提升超分辨率模型的性能。 记得残差块(Residual Block)在ResNet中被广泛使用,通过跳跃连接缓解梯度消失的问题,帮助训练更深的网络。而通道注意力机制,比如SENet中的Squeeze-and-Excitation模块,能够自动学习各个通道的重要性,增强有用的特征,抑制不重要的。RCAB可能结合了这两者。 接下来,需要确认RCAB的具体结构。根据常见的设计,RCAB可能包含多个卷积层,然后是通道注意力模块,最后通过残差连接相加。这样可以在提取特征的同时,动态调整各通道的权重,让网络更关注重要的信息。 在超分辨率任务中,RCAB的作用应该是增强高频细节的恢复,比如边缘和纹理,这对于提升图像清晰度至关重要。同时,通道注意力机制能有效利用通道间的依赖关系,优化特征表达,从而提升重建质量。 应用场景方面,RCAB可能被用于如EDSR、RCAN等超分辨率模型中。这些模型通常堆叠多个RCAB模块,通过深层的网络结构逐步恢复高分辨率图像。特别是在处理大倍数超分辨率(如4x、8x)时,RCAB能帮助保持细节,减少模糊。 还需要考虑RCAB的优势。比如,通过残差学习简化了优化过程,而通道注意力则增强了特征的区分能力。这可能使得模型在计算资源有限的情况下仍能保持高效,同时提升性能。 需要验证这些信息是否正确。参考用户提供的资料,引用[1]提到多尺度卷积和特征融合,引用[2]提到信息交互和注意力机制。虽然没有直接提到RCAB,但通道注意力属于注意力机制的一种,符合引用中的信息。因此可以推断RCAB的应用场景这些模块类似,用于特征提取和优化。 总结来说,RCAB的作用是通过残差结构和通道注意力机制,有效提取并优化特征,提升超分辨率重建的质量。应用场景包括各种基于深度学习的超分辨率模型,特别是在需要恢复细节和高效利用特征时。</think>RCAB(Residual Channel Attention Block)模块在图像超分辨率任务中主要用于**增强特征表达能力并优化高频细节恢复**,其核心原理是通过残差学习通道注意力机制的结合,动态调整特征通道的重要性权重。 ### 作用原理分步说明: 1. **残差学习框架** RCAB基于残差块(Residual Block)设计,包含两个卷积层和激活函数,通过跳跃连接(Skip Connection)将输入输出相加。这种方式缓解了梯度消失问题,支持更深的网络训练,公式为: $$F(x) = H(x) + x$$ 其中$H(x)$为残差函数,$x$为输入特征。 2. **通道注意力机制** 在残差块后引入通道注意力模块(Channel Attention Module),通过全局平均池化(Global Average Pooling)统计通道特征,并利用全连接层生成通道权重: $$w_c = \sigma(W_2 \cdot \delta(W_1 \cdot \text{GAP}(x)))$$ 其中$\sigma$为Sigmoid函数,$\delta$为ReLU,$W_1$和$W_2$为全连接层参数。最终输出特征为各通道加权后的结果: $$x' = w_c \cdot x$$ 该机制使网络自动关注对重建更重要的特征通道[^1]。 3. **多尺度特征融合** RCAB常多尺度特征提取模块结合(如引用[1]中提到的多尺度卷积层),通过不同感受野的卷积核捕获低频和高频信息,再利用通道注意力筛选关键特征,减少冗余计算,提升重建效率。 ### 应用场景 - **单图像超分辨率(SISR)**:如RCAN(Residual Channel Attention Networks)模型,通过堆叠多个RCAB模块恢复高分辨率图像的细节[^2]。 - **多模态超分辨率融合**:在红外可见光图像融合任务中,RCAB用于增强跨模态特征的表征能力,保留边缘和纹理信息[^1]。 - **轻量超分辨率网络**:由于通道注意力可抑制无效特征,RCAB在减少计算量的同时保持性能,适用于移动端部署。 ### 示例模型结构 ```python class RCAB(nn.Module): def __init__(self, channels): super().__init__() self.conv1 = nn.Conv2d(channels, channels, 3, padding=1) self.conv2 = nn.Conv2d(channels, channels, 3, padding=1) self.ca = ChannelAttention(channels) # 通道注意力模块 def forward(self, x): res = self.conv1(x) res = F.relu(res) res = self.conv2(res) res = self.ca(res) # 通道加权 return x + res # 残差连接 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值