ITPub博客

首页 > Linux操作系统 > Linux操作系统 > GREENPLUM介绍之数据库管理(五)- 数据库的备份和恢复

GREENPLUM介绍之数据库管理(五)- 数据库的备份和恢复

原创 Linux操作系统 作者:LEE_CHAO 时间:2011-04-19 16:31:43 0 删除 编辑
       GREENPLUM和许多关系型数据库一样从两个方面实现数据库数据的保护。一方面是通过数据库的备份恢复,实现数据仓库数据的保护。另一方面是通过冗余实现系统的容错,为数据仓库系统提供高可用性。
    这部分先介绍数据库的备份。GREENPLUM为数据库的备份提供了两种工具,一种是pg_dump,另一种是gp_dump。pg_dump是从postgre继承过来的工具,它只能通过MASTER节点采用串行方式备份数据库,可以本地备份,也可以远程备份。其具体的参数说明可以通过执行
pg_dump --help获取
用法:
  pg_dump [OPTION]... [DBNAME]

常用选项:
  -f, --file=FILENAME      备份文件的名称
  -F, --format=c|t|p       输出文件的格式,c表示二进制文件,t表示tar,p表示文本
  -i, --ignore-version     当服务版本不匹配时,忽略服务版本。
  -v, --verbose            verbose模式
  -Z, --compress=0-9       采用压缩模式存放备份结果,并指定压缩级别
  --help                   显示帮助
  --version                显示版本,然后退出

控制输出内容的选项
  -a, --data-only             备份中只含有数据,而没有schema信息。
  -b, --blobs                 在备份中包含大对象。
  -c, --clean                 在创建前,删除schema
  -C, --create                在备份文件中含有创建数据库的命令。
  -d, --inserts               备份数据使用insert命令模式
  -D, --column-inserts        备份数据使用insert命令模式,并提供列名。
  -E, --encoding=ENCODING     备份文件使用的字符集
  -n, --schema=SCHEMA         只备份特定的SCHEMA
  -N, --exclude-schema=SCHEMA 备份中排除特定的SCHEMA
  -o, --oids                  在备份中包含oid
  -O, --no-owner              如果采用文本格式备份,越过对象所有者的还原信息。
  -s, --schema-only           只备份SCHEMA的信息,而不备份它们的数据。
  -S, --superuser=NAME        如果使用文本格式,指定超级用户的名称
                             
  -t, --table=TABLE           只备份特定的表,视图,或者序列
  -T, --exclude-table=TABLE   备份中排除特定的表,视图或者序列。
  -x, --no-privileges         不备份权限(grant/revoke)
  --disable-dollar-quoting    只使用表中SQL的"",不需使用$$处理文本分割
 
  --use-set-session-authorization 使用SESSION AUTHORIZATION命令替代
                                  ALTER OWNER commands设置所有权
  --gp-syntax                 备份中的SQL使用GREENPLUM句法,默认选项
  --no-gp-syntax              备份中的SQL不使用GREENPLUM句法

连接选项
  -h, --host=HOSTNAME      数据库主机名,或者socket目录
  -p, --port=PORT          数据库服务端口
  -U, --username=NAME      指定用户名
  -W, --password           强制口令提示。

比如例子
pg_dump -f /home/gpadmin/backup/sales_bak -v -F c -p 5432  -h mdw -C -n sales_history sales_history
提供master的连接信息,把数据库sales_history的schema sales_history备份到/home/gpadmin/backup/sals_bak中,并含有建库句法。               
        这种备份方式实际上是一种逻辑备份方式,而非ORACLE RMAN那样的物理备份。它有两个主要的限制。一方面备份速度受MASTER节点数据吞吐能力的限制。另外,MASTER用来存放备份文件的空间必须足够大,能够存放所有segment节点的备份数据。所以这种方式更适合用在数据迁移的场景中.比如把postgre数据库(或者netezza)的数据迁移到greenplum中,或者在不同架构的GREENPLUM数据库间进行数据迁移,比如4节点的服务的数据,向8节点的服务迁移。
    对应pg_dump备份的结果,如果数据库出现故障,或者要进行数据移植,需要进行数据恢复,要使用工具pg_restore。具体参数说明可以通过pg_restore --help获取。
具体用法:
  pg_restore [OPTION]... [FILE]

常见选项:
  -d, --dbname=NAME        指定连接数据库的名称。
  -f, --file=FILENAME      输出文件名称
  -F, --format=c|t         指定备份文件格式,c表示自定义,t表示tar
  -i, --ignore-version     如果版本不匹配,忽略版本
  -l, --list               打印归档TOC的汇总信息
  -v, --verbose            使用verbose模式
  --help                   显示帮助,然后退出
  --version                显示版本,然后退出

控制还原的选项
  -a, --data-only          只还原数据
  -c, --clean              在创建之前删除schema
  -C, --create             创建目标数据库
  -I, --index=NAME         还原索引
  -L, --use-list=FILENAME  按照文件指定顺序还原表
  -n, --schema=NAME        只还原特定SCHEMA的对象
  -O, --no-owner           跳过特定所有者对象的还原
  -P, --function='NAME(args)' 还原特定的函数,函数的名字必须与TOC中的一致,并且使用单引号括起。
                  
  -s, --schema-only        只还原SCHEMA,不还原相关数据。
  -t, --table=NAME         只还原特定的表
  -x, --no-privileges      跳过特定权限的还原 (grant/revoke)
  --use-set-session-authorization 使用SESSION AUTHORIZATION替代 ALTER OWNER TO命令
  --no-data-for-failed-tables 不还原创建表失败的数据                        
  -1, --single-transaction    还原作为一个单一事务进行。
  
连接选项:
  -h, --host=HOSTNAME      指定数据库服务的主机名或者socket目录
  -p, --port=PORT          数据库服务端口号
  -U, --username=NAME      指定连接的数据库用户
  -W, --password           强制口令提示
  -e, --exit-on-error      遇到错误退出,默认模式是继续。

用刚才的备份为列,我们先删除sales表
sales_history=> select count(*) from sales;
 count
--------
 918843
(1 row)

sales_history=> select count(*) from sales;
ERROR:  relation "sales" does not exist
LINE 1: select count(*) from sales;
                             ^
sales_history=> \q

然后利用备份进行表级恢复
gpadmin@mdw:~/backup> pg_restore -F c -d sales_history -v  -t sales -h mdw -p 5432 -U sh  /home/gpadmin/backup/sales_bak
pg_restore: connecting to database for restore
Password:
pg_restore: creating TABLE sales
pg_restore: restoring data for table "sales"
pg_restore: setting owner and privileges for TABLE sales
完成恢复后检查表
sales_history=> select count(*) from sales;
 count
--------
 918843
(1 row)

需要注意的是,如果pg_dump备份的文件格式是txt平面文件,则不能用pg_restore进行恢复,应该考虑使用psql进行恢复。否则会得到如下错误信息
pg_restore: [archiver] did not find magic string in file header。这一点也完全适用于postgre数据库。

        对于海量数据仓库来而言,通过pg_dump/pg_restore进行备份/恢复,一方面在性能上无法满足业务对备份/恢复时间窗口要求,另外对MASTER可以访问的存储容积和性能也有比较高的要求。为了解决这两点问题,GREENPLUM在POSTGRESQL的基础上提供了自己的备份/恢复工具gp_dump/gp_restore。它们不需要通过master进行数据库的备份恢复,每个segment和master并行备份/恢复自己的数据,这样master就不会再成为瓶颈,从而大幅提高备份/恢复的速度。
    先看gp_dump的用法。同样可以通过gp_dump --help查看相关选项。
具体的句法
  gp_dump [OPTION]... [DBNAME]

常用选项:
  -i, --ignore-version    即使与服务版本不匹配,也继续处理
  -v, --verbose           使用verbose模式,显示处理过程的细节信息。并在每个段的状态文件中添加这些信息。
  --help                   查看帮助
  --version                输出版本信息,然后退出。

控制输出内容的选项
  -a, --data-only          只备份数据
  -c, --clean              在创建之前,先删除schema
  -d, --inserts            使用insert命令方式备份数据,而不是copy命令
  -D, --column-inserts     使用insert命令方式备份数据,并显示列信息
  -E, --encoding=ENCODING  指定备份数据使用的字符集
  -n, --schema=SCHEMA      只备份指定的shcema
  -N, --exclude-schema=SCHEMA 不备份指定的schema
  -o, --oids               备份中包含oid
  -O, --no-owner           采用文本格式时,不输出授权语句。
  -s, --schema-only        只备份schema的定义
  -S, --superuser=NAME     采用文本格式备份时,指定超级管理员
  -t, --table=TABLE        只备份特定的表,视图,索引和序列
  -T, --exclude-table=TABLE   不备份特定的表,视图,索引和序列
es)
  -x, --no-privileges     不备份授权语句
  --use-set-session-authorization 使用SESSION AUTHORIZATION替代
                              ALTER OWNER 命令去设置所有权
连接选项
  -h, --host=HOSTNAME      数据库服务主机(ip)或者socket目录
  -p, --port=PORT          数据库服务端口号
  -U, --username=NAME      连接用户
  -W, --password           强制口令提示,默认选项

Greenplum专有选项
  --gp-c                  用gzip进行内置备份压缩
  --gp-d=BACKUPFILEDIR    指定备份文件存放目录,这些目录应该存在于所有master主机和segment主机,或者为这些主机所共享。默认目录就是每个段和master的数据目录。
  --gp-r=REPORTFILEDIR    指定备份报告文件的存放目录,这些目录应该存在于所有master主机和segment主机,或者为这些主机所共享。默认目录就是每个段和master的数据目录。
  --gp-s=BACKUPSET        备份指示 - p表示备份所有primary segment。i指定特定的primary segment进行备份,要跟上特定segment的dbid。
比如我们要对sales_history进行全库备份。
gpadmin@mdw:~> gp_dump --gp-c sales_history
20110419:15:41:39|gp_dump-[INFO]:-Command line options analyzed.
20110419:15:41:39|gp_dump-[INFO]:-Connecting to master database on host localhost port 5432 database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-Reading Greenplum Database configuration info from master database.
20110419:15:41:39|gp_dump-[INFO]:-Preparing to dump the following segments:
20110419:15:41:39|gp_dump-[INFO]:-Segment 3 (dbid 5)
20110419:15:41:39|gp_dump-[INFO]:-Segment 2 (dbid 4)
20110419:15:41:39|gp_dump-[INFO]:-Segment 1 (dbid 3)
20110419:15:41:39|gp_dump-[INFO]:-Segment 0 (dbid 2)
20110419:15:41:39|gp_dump-[INFO]:-Master (dbid 1)
20110419:15:41:39|gp_dump-[INFO]:-Starting a transaction on master database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-Getting a lock on pg_class in database sales_history.
20110419:15:41:39|gp_dump-[INFO]:-About to spin off 5 threads with timestamp key 20110419154139
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 5: host sdw2 port 50003 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 4: host sdw2 port 50002 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 3: host mdw port 50001 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 2: host mdw port 50000 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Creating thread to backup dbid 1: host mdw port 5432 database sales_history
20110419:15:41:39|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to start transactions in serializable isolation level
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 3 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 1 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 2 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 5 connection
20110419:15:41:39|gp_dump-[INFO]:-Listening for messages from server on dbid 4 connection
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 1 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 3 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 2 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 5 server
20110419:15:41:39|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 4 server
20110419:15:41:42|gp_dump-[INFO]:-backup succeeded for dbid 1 on host mdw
20110419:15:41:42|gp_dump-[INFO]:-All remote gp_dump_agent processes have began transactions in serializable isolation level
20110419:15:41:42|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to obtain local locks on dumpable objects
20110419:15:41:42|gp_dump-[INFO]:-All remote gp_dump_agent processes have obtains the necessary locks
20110419:15:41:42|gp_dump-[INFO]:-Committing transaction on the master database, thereby releasing locks.
20110419:15:41:42|gp_dump-[INFO]:-Waiting for all remote gp_dump_agent programs to finish.
20110419:15:41:44|gp_dump-[INFO]:-backup succeeded for dbid 3 on host mdw
20110419:15:41:44|gp_dump-[INFO]:-backup succeeded for dbid 5 on host sdw2
20110419:15:41:45|gp_dump-[INFO]:-backup succeeded for dbid 4 on host sdw2
20110419:15:41:45|gp_dump-[INFO]:-backup succeeded for dbid 2 on host mdw
20110419:15:41:45|gp_dump-[INFO]:-All remote gp_dump_agent programs are finished.
20110419:15:41:45|gp_dump-[INFO]:-Report results also written to /data/gpmaster/gpseg-1/gp_dump_20110419154139.rpt.

Greenplum Database Backup Report
Timestamp Key: 20110419154139
gp_dump Command Line: --gp-c sales_history
Pass through Command Line Options: None
Compression Program: gzip

Individual Results
        segment 3 (dbid 5) Host sdw2 Port 50003 Database sales_history BackupFile /data/gpdb_p4/gpseg3/./gp_dump_0_5_20110419154139.gz: Succeeded
        segment 2 (dbid 4) Host sdw2 Port 50002 Database sales_history BackupFile /data/gpdb_p3/gpseg2/./gp_dump_0_4_20110419154139.gz: Succeeded
        segment 1 (dbid 3) Host mdw Port 50001 Database sales_history BackupFile /data/gpdb_p2/gpseg1/./gp_dump_0_3_20110419154139.gz: Succeeded
        segment 0 (dbid 2) Host mdw Port 50000 Database sales_history BackupFile /data/gpdb_p1/gpseg0/./gp_dump_0_2_20110419154139.gz: Succeeded
        Master (dbid 1) Host mdw Port 5432 Database sales_history BackupFile /data/gpmaster/gpseg-1/./gp_dump_1_1_20110419154139.gz: Succeeded
gp_dump utility finished successfully.
在master上
一方面可以看到报告文件,所有文件都有一个含有时间戳信息的14位编码,这个编码是将来恢复时选择备份的关键字,并且保证了每个段备份的一致性。
gp_dump_20110419154139.rpt 它提供所有段的备份情况
gp_dump_status_1_1_20110419154139 提供master的备份过程信息。
gp_cdatabase_1_1_20110419154139 提供了创建数据库的句法信息。
gp_dump_1_1_20110419154139.gz   master具体的备份数据。

在segment上,只有两个文件
gp_dump_status_0_2_20110419154139 提供了特定段备份的过程信息。
 gp_dump_0_2_20110419154139.gz    特定段的备份数据

对应gp_dump的备份需要通过gp_restore进行并行恢复。具体用法如下
gp_restore [OPTIONS]

常用选项
  -d, --dbname=NAME        指定数据库名称
  -i, --ignore-version     即使服务版本不匹配,忽略版本信息。
  -v, --verbose            用verbose模式. 并向每个段的状态文件中添加这些信息
  --help                   显示帮助然后退出
  --version               输出版本信息,然后退出

控制输出内容的选项
  -a, --data-only          只恢复数据
  -c, --clean              创建之前,删除schema
  -s, --schema-only        只恢复schema定义

连接选项
  -h, --host=HOSTNAME      指定数据库服务主机名或者socket目录
  -p, --port=PORT          指定连接端口号
  -U, --username=NAME      指定连接的用户
  -W, --password           强制口令提示

Greenplum 特有选项
  --gp-c                  如果备份时是压缩格式,必须恢复使用该选项解压
  --gp-d=BACKUPFILEDIR    指定备份文件目录,默认就是数据目录。
  --gp-i                  忽略错误
  --gp-k=KEY              指定备份14位时间戳信息,必须指定。
  --gp-r=REPORTFILEDIR    指定报告存放目录
  --gp-l=FILELOCATIONS    指定备份文件是在所有主段(p),还是特定的主段上。

比如刚才的备份进行恢复测试
我们可以先删除数据库sales_history
template1=# drop database sales_history;
DROP DATABASE
template1=# \l
                  List of databases
   Name    |  Owner  | Encoding |  Access privileges
-----------+---------+----------+---------------------
 postgres  | gpadmin | UTF8     |
 template0 | gpadmin | UTF8     | =c/gpadmin
                                : gpadmin=CTc/gpadmin
 template1 | gpadmin | UTF8     | =c/gpadmin
                                : gpadmin=CTc/gpadmin
 xjods     | gpadmin | UTF8     |
(4 rows)
下面进行恢复,再恢复之前,必须先重建数据库。这可以自己用命令创建,或者使用master上备份时产生脚本进行数据库的重新创建,比如
gpadmin@mdw:/data/gpmaster/gpseg-1> psql -d template1 -f gp_cdatabase_1_1_20110419154139
CREATE DATABASE
完成数据库创建之后,才能进行数据恢复。
gpadmin@mdw:~> gp_restore -d sales_history --gp-k=20110419154139 --gp-c
20110419:16:05:19|gp_restore-[INFO]:-Analyzed command line options.
20110419:16:05:19|gp_restore-[INFO]:-Connecting to master segment on host localhost port 5432 database sales_history.
20110419:16:05:19|gp_restore-[INFO]:-Reading Greenplum Database configuration info from master segment database.
20110419:16:05:19|gp_restore-[INFO]:-Preparing to restore the following segments:
20110419:16:05:19|gp_restore-[INFO]:-Segment 3 (dbid 5)
20110419:16:05:19|gp_restore-[INFO]:-Segment 2 (dbid 4)
20110419:16:05:19|gp_restore-[INFO]:-Segment 1 (dbid 3)
20110419:16:05:19|gp_restore-[INFO]:-Segment 0 (dbid 2)
20110419:16:05:19|gp_restore-[INFO]:-Master (dbid 1)
20110419:16:05:19|gp_restore-[INFO]:-Starting to restore the master database.
20110419:16:05:19|gp_restore-[INFO]:-Creating thread to restore master database: host mdw port 5432 database sales_history
20110419:16:05:19|gp_restore-[INFO]:-Listening for messages from dbid 1 server (source) for dbid 1 restore
20110419:16:05:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 1 to restore dbid 1
20110419:16:05:21|gp_restore-[INFO]:-restore started for source dbid 1, target dbid 1 on host mdw
20110419:16:06:19|gp_restore-[INFO]:-restore succeeded for source dbid 1, target dbid 1 on host mdw
20110419:16:06:19|gp_restore-[INFO]:-Successfully restored master database: host mdw port 5432 database sales_history
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 5 (sdw2:50003) from backup file on dbid 5 (sdw2:50003)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 4 (sdw2:50002) from backup file on dbid 4 (sdw2:50002)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 3 (mdw:50001) from backup file on dbid 3 (mdw:50001)
20110419:16:06:19|gp_restore-[INFO]:-Creating thread to restore dbid 2 (mdw:50000) from backup file on dbid 2 (mdw:50000)
20110419:16:06:19|gp_restore-[INFO]:-Waiting for all remote gp_restore_agent programs to finish.
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 5 server (source) for dbid 5 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 5 to restore dbid 5
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 4 server (source) for dbid 4 restore
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 2 server (source) for dbid 2 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 2 to restore dbid 2
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 4 to restore dbid 4
20110419:16:06:19|gp_restore-[INFO]:-Listening for messages from dbid 3 server (source) for dbid 3 restore
20110419:16:06:19|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 3 to restore dbid 3
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 3, target dbid 3 on host mdw
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 4, target dbid 4 on host sdw2
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 2, target dbid 2 on host mdw
20110419:16:06:22|gp_restore-[INFO]:-restore started for source dbid 5, target dbid 5 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 3, target dbid 3 on host mdw
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 5, target dbid 5 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 2, target dbid 2 on host mdw
20110419:16:06:26|gp_restore-[INFO]:-restore succeeded for source dbid 4, target dbid 4 on host sdw2
20110419:16:06:26|gp_restore-[INFO]:-All remote gp_restore_agent programs are finished.
20110419:16:06:26|gp_restore-[INFO]:-updating Append Only table statistics
20110419:16:06:27|gp_restore-[INFO]:-Report results also written to /data/gpmaster/gpseg-1/gp_restore_20110419154139.rpt.

Greenplum Database Restore Report
Timestamp Key: 20110419154139
gp_restore Command Line: -d sales_history --gp-k=20110419154139 --gp-c
Pass through Command Line Options: None
Compression Program: gunzip

Individual Results
        Restore of sales_history on dbid 1 (mdw:5432) from /data/gpmaster/gpseg-1/./gp_dump_1_1_20110419154139.gz: Succeeded
        Restore of sales_history on dbid 5 (sdw2:50003) from /data/gpdb_p4/gpseg3/./gp_dump_0_5_20110419154139.gz: Succeeded
        Restore of sales_history on dbid 4 (sdw2:50002) from /data/gpdb_p3/gpseg2/./gp_dump_0_4_20110419154139.gz: Succeeded
        Restore of sales_history on dbid 3 (mdw:50001) from /data/gpdb_p2/gpseg1/./gp_dump_0_3_20110419154139.gz: Succeeded
        Restore of sales_history on dbid 2 (mdw:50000) from /data/gpdb_p1/gpseg0/./gp_dump_0_2_20110419154139.gz: Succeeded

gp_restore  utility finished successfully.

GREENPLUM备份恢复机制类似oracle数据库的逻辑备份概念。基本上可以满足传统数据仓库对备份恢复的要求。但是GREENPLUM备份工具仍然存在局限性,比如无论是全库备份还是对象级别的备份只能是完全备份,而不支持增量备份。备份虽然是联机备份,但是在备份过程中会在备份的对象上加排他锁,从而影响系统的DML操作。当然,这些问题可以通过对大表进行分区的方式,进行一定的缓解。我们还是希望EMC在将来的版本上可以对GP的备份工具进行改进,使其更加完善好用。



 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25548387/viewspace-692867/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 昂贵的EXADATA V2
请登录后发表评论 登录
全部评论

注册时间:2011-03-18

  • 博文量
    70
  • 访问量
    379717