Greenplum数据库支持并行和非并行方法来备份和还原数据库。并行操作可扩展,而与系统中段的数量无关,因为段主机各自将数据同时写入本地磁盘存储中。对于非并行备份和还原操作,必须通过网络将数据从网段发送到主服务器,主服务器将所有数据写入其存储中。除了将I/O限制在一台主机之外,非并行备份还要求主服务器具有足够的本地磁盘存储空间来存储整个数据库。
Greenplum是MPP架构的分析型数据库,其核心源码从2015年的v4.3版本开始开源至今,已经有6年多的时间了,起初,开源版本的并行备份恢复工具叫gpcrondump和gpdbrestore。由于这个工具存在一些已知的缺陷,比如单独备份一个大压缩包导致单表恢复操作时间过长等,官方目前已经开发了替代工具gpbackup和gprestore并进行了开源,GitHub地址为:https://github.com/greenplum-db/gpbackup 。
gpbackup 和 gprestore 是Greenplum数据库备份和还原实例,采用MVCC机制来保障备份的数据,库级一致性。避免原来需要锁pg_class exclusive的问题。需要锁定元数据(catelog AccessShareLock),同时对备份对象加AccessShareLock锁,不允许drop已有的表,Alter已有的表结构,truncate已有表等操作(只允许AccessShareLock不冲突的操作)。但是可以在备份启动并加载完所有的accessshare lock后新增表以及对新增的表做任何DDL DML操作。
PostgreSQL的 pg_dump 和 pg_dumpall 非并行备份可用于在master主机上创建单个转储文件,其中包含来自所有活动段的所有数据。
PostgreSQL非并行备份仅应在特殊情况下使用。它们比使用Greenplum备份要慢得多,因为所有数据都必须通过master数据库。另外,通常情况下,master主机的磁盘空间不足,无法保存整个分布式Greenplum数据库的备份。
pg_restore 需要由创建的压缩转储文件 pg_dump/ pg_dumpall。开始还原之前,应该修改 CREATE TABLE 转储文件中的语句以包含Greenplum DISTRIBUTED 子句。如果不包括DISTRIBUTED子句,Greenplum数据库分配默认值,该值可能不是最佳值。 要使用并行备份文件执行非并行还原,可以将备份文件从每个段主机复制到主服务器主机,然后通过master服务器加载它们。
需要从Pivotal Network下载适用于的Greenplum数据库版本和OS平台的最新Pivotal Greenplum Backup and Restore软件发行版。
将安装包上传至master节点进行安装
[gpadmin@gp-mdw ~]$ gppkg -i pivotal_greenplum_backup_restore-1.25.0-gp6-rhel-x86_64.gppkg
20221017:09:36:32:021889 gppkg:gp-mdw:gpadmin-[INFO]:-Starting gppkg with args: -i pivotal_greenplum_backup_restore-1.25.0-gp6-rhel-x86_64.gppkg
20221017:09:36:33:021889 gppkg:gp-mdw:gpadmin-[INFO]:-Installing package pivotal_greenplum_backup_restore-1.25.0-gp6-rhel-x86_64.gppkg
20221017:09:36:33:021889 gppkg:gp-mdw:gpadmin-[INFO]:-Validating rpm installation cmdStr='rpm --test -i /usr/local/greenplum-db-6.22.0/.tmp/gpbackup_tools_RHEL-1.25.0-1.x86_64.rpm --dbpath /usr/local/greenplum-db-6.22.0/share/packages/database --prefix /usr/local/greenplum-db-6.22.0'
20221017:09:36:54:021889 gppkg:gp-mdw:gpadmin-[INFO]:-Installing pivotal_greenplum_backup_restore-1.25.0-gp6-rhel-x86_64.gppkg locally
20221017:09:36:54:021889 gppkg:gp-mdw:gpadmin-[INFO]:-Validating rpm installation cmdStr='rpm --test -i /usr/local/greenplum-db-6.22.0/.tmp/gpbackup_tools_RHEL-1.25.0-1.x86_64.rpm --dbpath /usr/local/greenplum-db-6.22.0/share/packages/database --prefix /usr/local/greenplum-db-6.22.0'
20221017:09:36:54:021889 gppkg:gp-mdw:gpadmin-[INFO]:-Installing rpms cmdStr='rpm -i --force /usr/local/greenplum-db-6.22.0/.tmp/gpbackup_tools_RHEL-1.25.0-1.x86_64.rpm --dbpath /usr/local/greenplum-db-6.22.0/share/packages/database --prefix=/usr/local/greenplum-db-6.22.0'
20221017:09:36:58:021889 gppkg:gp-mdw:gpadmin-[INFO]:-Completed local installation of pivotal_greenplum_backup_restore-1.25.0-gp6-rhel-x86_64.gppkg.
20221017:09:36:58:021889 gppkg:gp-mdw:gpadmin-[INFO]:-gpbackup 1.25.0 successfully installed
20221017:09:36:58:021889 gppkg:gp-mdw:gpadmin-[INFO]:-pivotal_greenplum_backup_restore-1.25.0-gp6-rhel-x86_64.gppkg successfully installed.
[gpadmin@gp-mdw ~]$
postgres软件自带,无需单独安装。
gpbackup 和 gprestore 与以下Greenplum数据库版本兼容:
gpbackup和 gprestore 有以下限制:
下表列出了备份和还原对象 gpbackup和 gprestore。将使用指定的数据库备份数据库对象–dbname选项。默认情况下,也会备份全局对象(Greenplum数据库系统对象),但是仅当包含–with-globals对于 gprestore
数据库(用于指定的数据库 –dbname) | 全局(要求 –with-globals 恢复选项) |
---|---|
[Schemas) | Databases |
Procedural language extensions | Database-wide configuration parameter settings (GUCs) |
Sequences | Resource group definitions |
Comments | Resource queue definitions |
Tables | Roles |
Indexes | GRANT assignments of roles to databases |
Owners | |
Writable External Tables (DDL only) | |
Readable External Tables (DDL only) | |
Functions | |
Aggregates | |
Casts | |
Types | |
Views | |
Materialized Views (DDL only) | |
Protocols | |
Triggers. (While Greenplum Database does not support triggers, any trigger definitions that are present are backed up and restored.) | |
Rules | |
Domains | |
Operators, operator families, and operator classes | |
Conversions | |
Extensions | |
Text search parsers, dictionaries, templates, and configurations |
注意:这些数据库不包含在备份中。
当还原到现有数据库时,当存在public数据库,gprestore将对象还原到public数据库。当还原到新数据库(使用–create db选项)时,gprestore在使用create database命令创建数据库时自动创建public数据库。该命令使用包含公共数据库的template0数据库。
[gpadmin@gp-mdw ~]$ gpbackup --help
gpbackup is the parallel backup utility for Greenplum
Usage:
gpbackup [flags]
Flags:
--backup-dir string # 所有备份文件将写入的目录的绝对路径
--compression-level int # 数据备份期间使用的压缩级别。有效值的范围取决于压缩类型(默认值为1)
--compression-type string # 数据备份期间使用的压缩类型。有效值为'gzip'、'zstd'(默认值为“gzip”)
--copy-queue-size int # 使用--single data file 选项进行备份时,gpbackup应排队的COPY命令数(默认值为1)
--data-only # 仅备份数据,不备份元数据
--dbname string # 要备份的数据库
--debug # 打印详细和调试日志消息
--exclude-schema stringArray # 备份除指定架构中的对象之外的所有元数据--可以多次指定排除架构
--exclude-schema-file string # 包含要从备份中排除的架构列表的文件
--exclude-table stringArray # 备份指定表以外的所有元数据--可以多次指定排除表。
--exclude-table-file string # 包含要从备份中排除的完全限定表列表的文件
--from-timestamp string # 用于建立当前增量备份的时间戳
--help # gpbackup帮助
--include-schema stringArray # 仅备份指定的架构--可以多次指定include架构。
--include-schema-file string # 包含要包含在备份中的架构列表的文件
--include-table stringArray # 仅备份指定的表--可以多次指定include表。
--include-table-file string # 包含要包含在备份中的完全限定表列表的文件
--incremental # 仅备份自上次备份以来已修改的AO表的数据
--jobs int # 备份数据时要使用的并行连接数(默认值为1)
--leaf-partition-data # 对于分区表,为每个叶分区创建一个数据文件,而不是为整个表创建一个文件
--metadata-only # 仅备份元数据,不备份数据
--no-compression # 跳过数据文件的压缩
--plugin-config string # 用于插件的配置文件
--quiet # 禁止显示非警告、非错误日志消息
--single-data-file # 将所有数据备份到单个文件,而不是每个表一个文件
--verbose # 打印详细日志消息
--version # 打印版本号并退出
--with-stats # 备份查询计划统计
--without-globals # 跳过全局元数据备份
[gpadmin@gp-mdw ~]$
创建备份目录
gpssh -f /home/gpadmin/all_host 'sudo mkdir /opt/backup'
gpssh -f /home/gpadmin/all_host 'sudo chmod -R 775 /opt/backup'
gpssh -f /home/gpadmin/all_host 'sudo chown -R gpadmin. /opt/backup'
要执行数据库以及Greenplum Database系统元数据的完整备份:
[gpadmin@gp-mdw ~]$ gpbackup --dbname test --backup-dir /opt/backup/ --leaf-partition-data
20221017:09:59:28 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-gpbackup version = 1.25.0
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Greenplum Database Version = 6.22.0 build commit:4b6c079bc3aed35b2f161c377e208185f9310a69 Open Source
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Starting backup of database test
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Backup Timestamp = 20221017095928
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Backup Database = test
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Gathering table state information
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Acquiring ACCESS SHARE locks on tables
Locks acquired: 5 / 5 [================================================================] 100.00% 0s
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Gathering additional table metadata
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Getting partition definitions
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Getting storage information
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Getting child partitions with altered schema
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Metadata will be written to /opt/backup/gpseg-1/backups/20221017/20221017095928/gpbackup_20221017095928_metadata.sql
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Writing global database metadata
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Global database metadata backup complete
20221017:09:59:29 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Writing pre-data metadata
20221017:09:59:30 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Pre-data metadata metadata backup complete
20221017:09:59:30 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Writing post-data metadata
20221017:09:59:30 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Post-data metadata backup complete
20221017:09:59:30 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Writing data to file
Tables backed up: 4 / 4 [==============================================================] 100.00% 0s
20221017:09:59:30 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Data backup complete
20221017:09:59:30 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Skipped data backup of 1 external/foreign table(s).
20221017:09:59:30 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-See /home/gpadmin/gpAdminLogs/gpbackup_20221017.log for a complete list of skipped tables.
20221017:09:59:32 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Found neither /usr/local/greenplum-db-6.22.0/bin/gp_email_contacts.yaml nor /home/gpadmin/gp_email_contacts.yaml
20221017:09:59:32 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Email containing gpbackup report /opt/backup/gpseg-1/backups/20221017/20221017095928/gpbackup_20221017095928_report will not be sent
20221017:09:59:32 gpbackup:gpadmin:gp-mdw:022347-[INFO]:-Backup completed successfully
[gpadmin@gp-mdw ~]$
上面的命令在master节点指定目录会创建一个包含全局和特定于数据库的元数据的文件,否则默认目录的Greenplum数据库主主机上的如下目录。
/opt/backup/gpseg-1/backups/20221017/20221017095928
备份包含以下内容:
[gpadmin@gp-mdw 20221017095928]$ ll
total 20
-r--r--r-- 1 gpadmin gpadmin 801 Oct 17 09:59 gpbackup_20221017095928_config.yaml
-r--r--r-- 1 gpadmin gpadmin 3621 Oct 17 09:59 gpbackup_20221017095928_metadata.sql
-r--r--r-- 1 gpadmin gpadmin 1834 Oct 17 09:59 gpbackup_20221017095928_report
-r--r--r-- 1 gpadmin gpadmin 4989 Oct 17 09:59 gpbackup_20221017095928_toc.yaml
[gpadmin@gp-mdw 20221017095928]$
Segment 节点也会在相同的目录生成备份文件,每个段都将用于备份的每个表的数据存储在单独的压缩CSV文件中, 否则会在如下目录
/opt/backup/gpseg12/backups/20221017/20221017095928/
备份包含以下内容:
[root@gp-sdw03 20221017095928]# ll
total 16
-rw-------. 1 gpadmin gpadmin 20 Oct 17 09:59 gpbackup_12_20221017095928_16506.gz
-rw-------. 1 gpadmin gpadmin 20 Oct 17 09:59 gpbackup_12_20221017095928_16511.gz
-rw-------. 1 gpadmin gpadmin 20 Oct 17 09:59 gpbackup_12_20221017095928_16519.gz
-rw-------. 1 gpadmin gpadmin 20 Oct 17 09:59 gpbackup_12_20221017095928_16534.gz
[root@gp-sdw03 20221017095928]#
注意:备份实例化视图不会备份实例化视图数据。仅备份实例化视图定义。
gpbackup 和 gprestore支持创建追加优化表的增量备份以及从增量备份还原。仅当表已更改时,增量备份才会备份所有指定的堆表,并备份追加优化的表(包括追加优化的,面向列的表)。例如,如果追加优化表的一行已更改,则将备份该表。对于分区的附加优化表,仅备份更改的叶子分区。
当追加优化表或表分区中已更改的数据总量与自上次备份以来未更改的数据相比较小时,增量备份将非常有效。
仅当上次完全备份或增量备份之后对表执行了以下操作之一时,增量备份才会备份追加优化的表:
增量备份集包括以下备份:
使用以下命令创建了增量备份:
gpbackup --dbname gpdw --backup-dir /data/backup/ --leaf-partition-data --incremental
在该示例中,完整备份具有时间戳20200514000143,20200514001027是增量备份。
[gpadmin@node1 gpseg-1]$ gpbackup_manager list-backups
timestamp date database type object filtering plugin duration date deleted
20200514001027 Thu May 14 2020 00:10:27 gpdw incremental 00:00:35
20200514000143 Thu May 14 2020 00:01:43 gpdw full 00:00:35
要基于最新的增量备份创建新的增量备份,必须包含相同的内容。
gpbackup --dbname mytest --backup-dir /mybackup --leaf-partition-data --incremental
可以指定 –from-timestamp 选项以基于现有的增量或完整备份创建增量备份。
使用 gprestore从备份集还原,必须使用 –timestamp 选项以指定确切的时间戳记值(YYYYMMDDHHMMSS) 恢复。如果数据库在群集中不存在,则选择–create-db,如果备份指定–backup-dir,则恢复时也需要指定 –backup-dir 。gprestore默认情况下不尝试还原Greenplum系统的全局元数据。如果需要,请使用–with-globals。默认gprestore使用1个连接来还原表数据和元数据。如果的备份集很大,则可以通过增加并行连接数–jobs 来提高还原性能。
gprestore --backup-dir /data/backup/ --timestamp 20200514001813 --create-db --with-globals -jobs 8
注意:不能使用 gpbackup 选项 –single-data-file执行并行还原操作 gprestore 如果备份合并表将每个段备份到单个文件。
恢复视图不会还原实例化视图数据。仅还原实例化视图定义。要用数据填充实例化视图,请使用刷新材料视图。刷新实例化视图时,实例化视图定义引用的表必须可用。gprestore 日志文件列出了已还原的实例化视图以及 刷新材料视图 用于用数据填充实例化视图的命令。
从增量备份还原时, gprestore 还列出了还原操作中使用的备份 gprestore 日志文件。
在还原操作期间, gprestore 如果完全备份或其他所需的增量备份不可用,则显示错误。 要创建增量备份或从增量备份集还原数据,需要完整的备份集。归档增量备份时,必须归档完整的备份集。必须归档在主数据库和所有段上创建的所有文件。
每一次 gpbackup 运行时,该实用程序将备份信息添加到历史文件 gpbackup_history.yaml在Greenplum数据库主数据目录中。该文件包括备份选项和其他备份信息。
如果不指定 –from-timestamp 创建增量备份时选择 gpbackup使用具有一组一致选项的最新备份。该实用程序将检查备份历史记录文件,以找到具有一致选项集的备份。如果该实用程序找不到具有一致选项集的备份,或者历史文件不存在,gpbackup 显示一条消息,指出必须先创建完整备份,然后才能创建增量文件。
如果指定 –from-timestamp 创建增量备份时选择 gpbackup 确保正在创建的备份的选项与指定备份的选项一致。
gpbackup 选项 –with-stats不必要求备份集中的所有备份都相同。但是,要使用gprestore 选项 –with-stats 要还原统计信息,指定的备份必须已使用 –with-stats 创建备份时。
可以从备份集中的任何备份执行还原操作。但是,增量备份中捕获的更改晚于用于还原数据库数据的备份时,将无法还原。
从增量备份集还原时, gprestore 检查备份,并从备份集中的附录优化表的最新版本中还原每个附录优化表,并从最新备份中还原堆表。
增量备份集,完整备份和关联的增量备份必须位于单个设备上。例如,备份集中的备份必须全部在文件系统上或必须全部在Data Domain系统上。
警告:对Greenplum数据库段配置的更改会使增量备份无效。更改段配置(添加或删除段实例)之后,必须先创建完整备份,然后才能创建增量备份。
执行备份操作时,gpbackup会将备份信息附加到Greenplum数据库主数据目录中的gpbackup_history.yaml文件中。该文件包含备份时间戳、有关备份选项的信息以及增量备份的备份集信息。此文件未由gpbackup备份。
当使用–incremental选项运行gpbackup时,gpbackup使用文件中的信息来查找增量备份的匹配备份,而不指定–from timesamp选项来指示要用作增量备份集中最新备份的备份。
[gpadmin@gp-mdw gpseg-1]$ cat gpbackup_history.yaml
backupconfigs:
- backupdir: /opt/backup/
backupversion: 1.25.0
compressed: true
compressiontype: gzip
databasename: test
databaseversion: 6.22.0 build commit:4b6c079bc3aed35b2f161c377e208185f9310a69 Open
Source
dataonly: false
datedeleted: ""
excluderelations: []
excludeschemafiltered: false
excludeschemas: []
excludetablefiltered: false
includerelations: []
includeschemafiltered: false
includeschemas: []
includetablefiltered: false
incremental: false
leafpartitiondata: true
metadataonly: false
plugin: ""
pluginversion: ""
restoreplan:
- timestamp: "20221017095928"
tablefqns:
- public.test_copy
- public.test_gpfdist
- public.test_log_gpload
- public.test_gpload
singledatafile: false
timestamp: "20221017095928"
endtime: "20221017095932"
withoutglobals: false
withstatistics: false
status: Success
[gpadmin@gp-mdw gpseg-1]$
在gpbackup或者 gprestore完成后返回的状态码含义
gpbackup 备份指定数据库中的所有数据库和表,除非使用数据库级或表级过滤器选项排除或包括单个数据库或表对象。
模式级别选项是 –include-schema 或者–exclude-schema
$ gpbackup --dbname gpdw --include-schema test
$ gpbackup --dbname gpdw --include-table-file /home/gpadmin/table-list.txt
可以结合 -include模式 与 –exclude-table 要么 –exclude-table-file进行备份。这个例子使用 –include模式 与 –exclude-table 备份除单个表以外的其他模式。
$ gpbackup --dbname gpdw --include-schema test --exclude-table mydata.addresses
不能结合 –include模式 与 –include-table 要么 –include-table-file,并且无法合并 -排除模式 使用任何表过滤选项,例如 –exclude-table 要么 –include-table。
使用时 –include-table 要么 –include-table-file 从属对象不会自动备份或还原,必须显式指定所需的从属对象。例如,如果备份或还原视图或实例化视图,则还必须指定该视图或实例化视图使用的表。如果备份或还原使用顺序的表,则还必须指定顺序。
gpbackup为段上的每个表创建一个文件。可以指定–leaf-partition-data选项可为分区表的每个叶分区创建一个数据文件,而不是单个文件。还可以通过在要包括的文本文件中列出叶分区名称来筛选到特定叶分区的备份。例如,考虑使用以下语句创建的表:
CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date)
( PARTITION Jan17 START (date '2017-01-01') INCLUSIVE ,
PARTITION Feb17 START (date '2017-02-01') INCLUSIVE ,
PARTITION Mar17 START (date '2017-03-01') INCLUSIVE ,
PARTITION Apr17 START (date '2017-04-01') INCLUSIVE ,
PARTITION May17 START (date '2017-05-01') INCLUSIVE ,
PARTITION Jun17 START (date '2017-06-01') INCLUSIVE ,
PARTITION Jul17 START (date '2017-07-01') INCLUSIVE ,
PARTITION Aug17 START (date '2017-08-01') INCLUSIVE ,
PARTITION Sep17 START (date '2017-09-01') INCLUSIVE ,
PARTITION Oct17 START (date '2017-10-01') INCLUSIVE ,
PARTITION Nov17 START (date '2017-11-01') INCLUSIVE ,
PARTITION Dec17 START (date '2017-12-01') INCLUSIVE
END (date '2018-01-01') EXCLUSIVE );
NOTICE: CREATE TABLE will create partition "sales_1_prt_jan17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_feb17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_mar17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_apr17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_may17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_jun17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_jul17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_aug17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_sep17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_oct17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_nov17" for table "sales"
NOTICE: CREATE TABLE will create partition "sales_1_prt_dec17" for table "sales"
要仅备份一年最后一个季度的数据,请首先创建一个文本文件,该文件列出这些叶分区名称而不是完整的表名称:
public.sales_1_prt_oct17
public.sales_1_prt_nov17
public.sales_1_prt_dec17
然后使用 –include-table-file 每个叶分区生成一个数据文件的选项:
$ gpbackup --dbname gpdw --include-table-file last-quarter.txt --leaf-partition-data
当指定 –leaf-partition-data,gpbackup备份分区表时,每个叶分区生成一个数据文件。例如,此命令为每个叶分区生成一个数据文件:
$ gpbackup --dbname gpdw --include-table public.sales --leaf-partition-data
备份叶分区时,叶分区数据与整个分区表的元数据一起备份。
注意:不能使用–exclude-table-file 与选项 -叶分区数据。尽管可以在使用以下命令指定的文件中指定叶分区名称–exclude-table-file, gpbackup 忽略分区名称。
使用gpbackup创建备份集后,可以使用gprestore–include schema和–include table file选项筛选要从备份集中还原的架构和表。这些选项的工作方式与gpbackup对应选项相同,但有以下限制:
警告:全部gpbackup元数据文件是使用只读权限创建的。切勿删除或修改元数据文件gpbackup 备份集。这样做会使备份文件无法正常工作。
完整备份集 gpbackup 包括多个元数据文件,支持文件和CSV数据文件,每个文件都有创建备份的时间戳。
默认情况下,元数据和支持文件存储在Greenplum数据库master主机的 $MASTER_DATA_DIRECTORY/backups/YYYYMMDD/YYYYMMDDHHMMSS/ 目录中。如果指定自定义备份目录,则将同一文件路径创建为备份目录的子目录。下表描述了元数据和支持文件的名称和内容。
文件名 | 描述 |
---|---|
gpbackup_ _metadata.sql | 包含全局和特定于数据库的元数据:DDL用于Greenplum数据库集群中全局的对象,而不是集群中特定数据库所拥有的对象。备份数据库中对象的DDL(指定为 –dbname)在还原实际数据之前必须创建的对象,以及在 还原数据之后必须创建的对象的DDL 。全局对象包括:TablespacesDatabasesDatabase-wide configuration parameter settings (GUCs)Resource group definitionsResource queue definitionsRolesGRANT assignments of roles to databasesNote: Global metadata is not restored by default. You must include the –with-globals option to the gprestore command to restore global metadata.Database-specific objects that must be created before to restoring the actual data include:Session-level configuration parameter settings (GUCs)SchemasProcedural language extensionsTypesSequencesFunctionsTablesProtocolsOperators and operator classesConversionsAggregatesCastsViewsMaterialized Views Note: Materialized view data is not restored, only the definition.ConstraintsDatabase-specific objects that must be created after restoring the actual data include:IndexesRulesTriggers. (While Greenplum Database does not support triggers, any trigger definitions that are present are backed up and restored.) |
gpbackup_ _toc.yaml | 包含用于在_predata.sql和_postdata.sql文件中定位对象DDL的元数据 。该文件还包含表名和OID,这些表名和OID用于在每个段上创建的CSV数据文件中定位相应的表数据。 |
gpbackup_ _报告 | 包含有关备份操作的信息,该信息用于填充备份完成后发送的电子邮件通知(如果已配置)。 |
gpbackup_ _config.yaml | 包含有关特定备份任务执行的元数据,包括:gpbackup 版数据库名称Greenplum数据库版本其他选项设置,例如 -无压缩, -压缩级别, -仅元数据, -仅数据和 –with-stats。 |
gpbackup_history.yaml | 包含有关使用以下命令创建备份时使用的选项的信息 gpbackup,以及有关增量备份的信息。存储在Greenplum数据库主数据目录中的Greenplum数据库主主机上。该文件不由备份 gpbackup。 |
默认情况下,每个段都为该段上备份的每个表创建一个压缩的CSV文件。可以选择指定-单个数据文件选项,以便在每个段上创建一个数据文件。文件存储在 <seg_dir> / backups / YYYYMMDD / YYYYMMDDHHMMSS /中。
如果指定自定义备份目录,则段数据文件将作为备份目录的子目录复制到同一文件路径。如果包括 -叶分区数据 选项, gpbackup 为分区表的每个叶分区创建一个数据文件,而不是为文件创建一个表。
每个数据文件使用文件名格式 gpbackup_<content_id> _ _ .gz,其中:
可以选择使用(1-9)指定gzip压缩级别 -压缩级别 选项,或完全禁用压缩 -无压缩。如果未指定压缩级别, gpbackup 默认情况下使用压缩级别1。
在Greenplum中,我们可以使用 gp_restore 或者 gpdbrestore 对数据库进行并行恢复,但是并行恢复要求要恢复的新集群与备份集群拥有同样的配置(节点实例数量)。但是如果我们的新集群节点数与原集群不一样怎么办?还能使用原备份文件吗?答案是肯定的,但是由于节点数量不一样了,我们只能通过Master节点进行非并行备份。
数据库的导入导出是最常用的功能之一,每种数据库都提供有这方面的工具,例如Oracle的exp/imp,Informix的dbexp/dbimp,MySQL的mysqldump,而PostgreSQL提供的对应工具为pg_dump和pg_restore。 pg_dump是用于备份PostgreSQL数据库的工具。它可以在数据库正在使用的时候进行完整一致的备份,并不阻塞其它用户对数据库的访问。 转储格式可以是一个脚本或者归档文件。转储脚本的格式是纯文本,包含许多SQL命令,这些SQL命令可以用于重建该数据库并将之恢复到保存脚本时的状态。可以使用 psql从这样的脚本中恢复。它们甚至可以用于在其它机器甚至是其它硬件体系的机器上重建数据库,通过对脚本进行一些修改,甚至可以在其它SQL数据库产品上重建数据库。 归档文件格式必须和pg_restore一起使用重建数据库。它们允许pg_restore对恢复什么东西进行选择,甚至是在恢复之前对需要恢复的条目进行重新排序。归档文件也是可以跨平台移植的。
pg_dump 把一个数据库转储为纯文本文件或者是其它格式
pg_restore 从一个归档中恢复一个由 pg_dump 创建的 PostgreSQL 数据库.
pg_dump进行单个数据库的备份,而pg_dumpall备份一个给出的集群中的每个数据库,同时还确保保留象用户和组这样的全局数据状态。
查看 Greenplum 集群状态:
# 1. 查看所有 gp 节点状态
select * from gp_segment_configuration;
# 2. 查看 gp 正在执行那些 sql
select * from * from pg_stat_activity;
# 3. 查看 gp 节点状态,4.3之前是 gpstate -m
gpstate -s;
Greenplum数据库属于OLAP型数据库,其数据多为历史数据,所以其数据量也是非常的大,一般是TB级别,甚至是PB级别,因此对Greenplum做备份恢复方案选型时,备份的效率应该是首要考虑的因素,Greenplum原生支持pg_dump、外部表导出数据、gpcrondump三种备份备份方式:
其中grcrondump/gpdbrestore方案具有以下优点:
尽管grcrondump/gpdbrestore方案有以上的优点,但由于是分布式并行备份,其备份文件分布在master和各segment节点的不同数据目录下。
可以配合Hadoop文件系统,需要将所有的备份文件都会上传到HDFS上进行存储,这就涉及到如何将分布的备份文件上传到HDFS上。我们通过在所有机器上部署hadoop客户端,在备份完成后直接从各segment上上传备份文件到HDFS上。 除了在HDFS保存一定存量的备份文件外,本地磁盘也应该有一定存量的备份文件,以便在恢复时减少下载数据的时间。
GP 同时备份 Master 和所有活动的 Segment 实例,备份消耗的时间与系统中实例的数量没有关系。在 Master 主机上备份所有 DDL 文件和 GP 相关的数据字典表,每个 Segment 备份各自的数据。所有备份文件组成一个完整的备份集合,通过唯一 14 位数字的时间戳来识别。
执行GP数据库备份
$ gp_dump testdw
调整selinux安全级别,/usr/sbin/setenforce 0
gp_dump命令将在数据目录生成如下的备份文件:
gpcrondump在Master和Segment的数据目录创建备份文件:
<data_directory>/db_dumps/YYYYMMDD
Segment数据的备份使用gzip压缩格式
使用 CRON 调度备份操作,定义一个调用 gpcrondump 的 crontab 条目 例如,在午夜1点备份testdw数据库
0 1 0 * * * gpadmin source $GPHOME/greenplum_path.sh; gpcrondump –x testdw –c –g –G –a –q >> gp_testdwdump.log
创建一个名为mail_contacts的文件放置在GP SUPERUSER的根目录,在该文件中,每行输入一个电邮地址。
# cat /home/gpadmin/mail_contacts
dba@company.com
GP 依然支持常规的 PostgreSQL 备份命令 pg_dump 和 pg_dumpall,备份将在 Master 主机上创建一个包含所有 Segment 数据的大的备份文件。因此, 不适合于全部数据备份,适用于小部分数据的迁移或备份。
# 导出testdw数据库到SQL脚本文件
pg_dump testdw > testdw.sql
# 导出包含分布键信息的testdw数据库到tar文件
pg_dump –Ft –gp-syntax testdw > testdw.tar
# 导出testdw数据库到定制格式的归档文件
pg_dump –Fc testdw > testdw.dump
# 导出单个表
pg_dump –t tb_cp_02 testdw > tb_cp_02_testdw.sql
# 导出混合大小写名称的表
pg_dump –t ‘”MixedTableName”’ testdw > tab_testdw.sql
# 集群备份
pg_dumpall > all.dump
在决定使用恢复程序时,需确定以下几个问题:
通过 gp_dump 产生唯一14位数字的时间戳来辨识备份集合,恢复数据库对象和数据到分布式数据库中,每个 Segment 并行恢复各自的数据。被恢复的 GP 系统必须与备份的系统同构,否则只能使用串行恢复。
如果在备份时使用了参数:-s(仅模式),-a(仅数据),–gp-c(压缩),–gp-d(修改备份文件目录),那么在恢复时也要指定这些参数。
gp_restore 命令将执行如下操作: (1) 在 Master 主机上 运行由 gp_dump 生成的 gp_dump_1_<dbid>_<timestamp> 文件中 SQL DDL 命令,重建数据库的模式和对象; 在 Master 数据目录生成日志文件,日志文件的名称为:gp_restore_status_1__<dbid>_<timestamp> gp_restore 在每个需要恢复的 Instance 上启动一个名为 gp_restore_agent 的程序,gp_restore_agent 进程在 Segment 主机上运行并向 Master 主机上的 gp_restore 进程报告状态
(2) 在 Segment 主机上 每个 Instance 使用 gp_dump 生成的 gp_dump_1_<dbid>_<timestamp> 文件来恢复用户数据 每个 Instance 生成一个日志文件,名字为:gp_restore_status_1__<dbid>_<timestamp>
恢复操作: step 1.创建需要被恢复的数据库。例如:
$ createdb testdw
step 2.在Master主机,运行gp_restore命令(–gp-k指定备份操作时间戳标识符,-d指定恢复的数据库)
$ gp_restore –gp-k=20131231001327 –d testdw
gpdbrestore 命令是对 gp_restore 命令的包装,提供更灵活的选项,使用 gpcrondump 备份生成的备份文件来进行恢复。
恢复testdw数据 step 1.创建需要被恢复的数据库。例如:
createdb testdw
step 2.在Master主机上执行gpdbrestore命令(-R指定备份文件所在的主机名和路径)
$ gpdbrestore –b 20131231
或者从归档主机恢复(-R指定备份文件所在的主机名和路径)
$ gpdbrestore –R archive_host:/gpdb/backups/archive/20131231
使用由 pg_dump 或 pg_dumpall 创建的备份文件来恢复,使用非并行恢复可以实现异构系统恢复。
使用 pg_restore 或 psql 进行恢复
pg_restore –d dbname dbname.dump;
psql -d dbname –f tb_cp_02_dbname.sql;
确保具备了全部的备份文件,包括 Master 和每一个 Segment 的文件,所有的文件具有相同的时间戳标识符 step 1. 创建需要恢复的数据库
createdb dbname;
step 2. 装载 Master 备份文件以恢复数据库对象
psql -d dbname -f /data/backups/gp_dump_1_1_20131231001327;
step 3. 装载每个 Segment 的备份文件以恢复数据
psql –d dbname -f /data/backups/gp_dump_0_2_20131231001327;
psql –d dbname -f /data/backups/gp_dump_0_3_20131231001327;
step 4. 恢复 Table 相关的对象,比如索引、触发器、主键约束等
psql –d dbname -f /data/backups/gp_dump_1_1_20131231001327_post_data;