greenplum备份与恢复

虽然GP有了MIRROR与STANDBY的保护，但是其仍然提供了一些备份与恢复功能。下面简单的介绍一下，就当是写学习笔记吧。
GP提供了三种备份的方式：

• Create a dump file for each segment with gp_dump
• Schedule routine dumps with gpcrondump
• Create a single dump file with pg_dump or pg_dumpall

pg_dump和pg_dumpall两种备份工具是在postgresql里就已经有的了。日常中比较方便的应该是gp_dump以及gpcrondump，从字面上也可以看出来，后者大体上就是对前者进行了一层封装，让我们使用上去更加便利。
我就使用pg_dump试一下吧。在使用pg_dump了以后会产生一些备份文件，下面是摘自GPADMIN文档里的一段内容，详细的讲解了这些文件
The gp_dump utility performs the following actions and produces the following dump files:
On the master host

• Dumps the Greenplum configuration system catalog tables into a SQL file in the master data directory. The default naming convention of this file is gp_catalog_1_<dbid>_<timestamp>.//很奇怪我好像没看到这个文件
• Dumps a CREATE DATABASE SQL statement into a file in the master data directory. The default naming convention of this file is gp_cdatabase_1_<dbid>_<timestamp>. This statement can be run on the master instance to recreate the database.
• Dumps the database schema(s) into a SQL file in the master data directory. The default naming convention of this file is gp_dump_1_<dbid>_<timestamp>. This file is used to recreate the database objects.
• Creates a log file in the master data directory named gp_dump_status_1_<dbid>_<timestamp>.
• gp_dump launches a gp_dump_agent for each segment instance to be backed up. gp_dump_agent processes run on the segment hosts and report status back to the gp_dump process running on the master host.

On the segment hosts

• Dumps the data for each segment instance into a SQL file in the segment instance’s data directory. By default, only primary (or active) segment instances are backed up. The default naming convention of this file is gp_dump_0_<dbid>_<timestamp>. This file is used to recreate that particular segment of data.
• Creates a log file in each segment instance’s data directory named gp_dump_status_0_<dbid>_<timestamp>.

Note that the 14 digit timestamp is the number that uniquely identifies the backup job, and is part of the filename for each dump file created by a gp_dump operation. This timestamp must be passed to the gp_restore utility when restoring a Greenplum database.

当然，你也可以通过--gp-d参数指定这些备份文件到某一个特定的目录下，其他一些参数的详细说明可以参考GPADMIN文档。下面是操作记录

[gpadmin1@hadoop4 ~]$ psql
psql (8.2.14)
Type "help" for help.

aligputf8=# select * from gp_segment_configuration;
 dbid | content | role | preferred_role | mode | status | port  | hostname | address | replication_port | san_mounts
------+---------+------+----------------+------+--------+-------+----------+---------+------------------+------------
    1 |      -1 | p    | p              | s    | u      |  5432 | hadoop4  | hadoop4 |                  |
    2 |       0 | p    | p              | s    | u      | 40000 | hadoop4  | hadoop4 |            41000 |
    4 |       2 | p    | p              | s    | u      | 40000 | hadoop5  | hadoop5 |            41000 |
    6 |       4 | p    | p              | s    | u      | 40000 | hadoop6  | hadoop6 |            41000 |
    3 |       1 | p    | p              | s    | u      | 40001 | hadoop4  | hadoop4 |            41001 |
    5 |       3 | p    | p              | s    | u      | 40001 | hadoop5  | hadoop5 |            41001 |
    7 |       5 | p    | p              | s    | u      | 40001 | hadoop6  | hadoop6 |            41001 |
    8 |       0 | m    | m              | s    | u      | 50000 | hadoop5  | hadoop5 |            51000 |
    9 |       1 | m    | m              | s    | u      | 50001 | hadoop5  | hadoop5 |            51001 |
   10 |       2 | m    | m              | s    | u      | 50000 | hadoop6  | hadoop6 |            51000 |
   11 |       3 | m    | m              | s    | u      | 50001 | hadoop6  | hadoop6 |            51001 |
   12 |       4 | m    | m              | s    | u      | 50000 | hadoop4  | hadoop4 |            51000 |
   13 |       5 | m    | m              | s    | u      | 50001 | hadoop4  | hadoop4 |            51001 |
   14 |      -1 | m    | m              | s    | u      |  5432 | hadoop5  | hadoop5 |                  |
(14 rows)

aligputf8=# create table t1(id int);
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
aligputf8=# insert into t1 values(1);
INSERT 0 1
aligputf8=# insert into t1 values(2);
INSERT 0 1
aligputf8=# insert into t1 values(3);
INSERT 0 1
aligputf8=# select * from t1;
 id
----
  1
  3
  2
(3 rows)

aligputf8=# /q
[gpadmin1@hadoop4 ~]$ ls
cxf  data  gp4datam1  gp4datam2  gp4datap1  gp4datap2  gp4master  gpAdminLogs  gpmaster.tar  hy
[gpadmin1@hadoop4 ~]$ mkdir backups
[gpadmin1@hadoop4 ~]$ cd backups/
[gpadmin1@hadoop4 backups]$ pwd
/home/gpadmin1/backups
[gpadmin1@hadoop4 backups]$ gp_dump --gp-d=/home/gpadmin1/backups aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Command line options analyzed.
20101030:19:07:28|gp_dump-[INFO]:-Connecting to master database on host localhost port 5432 database aligputf8.
20101030:19:07:28|gp_dump-[INFO]:-Reading Greenplum Database configuration info from master database.
20101030:19:07:28|gp_dump-[INFO]:-Preparing to dump the following segments:
20101030:19:07:28|gp_dump-[INFO]:-Segment 5 (dbid 7)
20101030:19:07:28|gp_dump-[INFO]:-Segment 4 (dbid 6)
20101030:19:07:28|gp_dump-[INFO]:-Segment 3 (dbid 5)
20101030:19:07:28|gp_dump-[INFO]:-Segment 2 (dbid 4)
20101030:19:07:28|gp_dump-[INFO]:-Segment 1 (dbid 3)
20101030:19:07:28|gp_dump-[INFO]:-Segment 0 (dbid 2)
20101030:19:07:28|gp_dump-[INFO]:-Master (dbid 1)
20101030:19:07:28|gp_dump-[INFO]:-Starting a transaction on master database aligputf8.
20101030:19:07:28|gp_dump-[INFO]:-Getting a lock on pg_class in database aligputf8.
20101030:19:07:28|gp_dump-[INFO]:-About to spin off 7 threads with timestamp key 20101030190728
20101030:19:07:28|gp_dump-[INFO]:-Creating thread to backup dbid 7: host hadoop6 port 40001 database aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Creating thread to backup dbid 6: host hadoop6 port 40000 database aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Creating thread to backup dbid 5: host hadoop5 port 40001 database aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Creating thread to backup dbid 4: host hadoop5 port 40000 database aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Creating thread to backup dbid 3: host hadoop4 port 40001 database aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Creating thread to backup dbid 2: host hadoop4 port 40000 database aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Creating thread to backup dbid 1: host hadoop4 port 5432 database aligputf8
20101030:19:07:28|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to start transactions in serializable isolation level
20101030:19:07:28|gp_dump-[INFO]:-Listening for messages from server on dbid 4 connection
20101030:19:07:28|gp_dump-[INFO]:-Listening for messages from server on dbid 3 connection
20101030:19:07:28|gp_dump-[INFO]:-Listening for messages from server on dbid 5 connection
20101030:19:07:28|gp_dump-[INFO]:-Listening for messages from server on dbid 2 connection
20101030:19:07:28|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 4 server
20101030:19:07:28|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 5 server
20101030:19:07:28|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 3 server
20101030:19:07:28|gp_dump-[INFO]:-Listening for messages from server on dbid 7 connection
20101030:19:07:28|gp_dump-[INFO]:-Listening for messages from server on dbid 6 connection
20101030:19:07:28|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 2 server
20101030:19:07:28|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 7 server
20101030:19:07:28|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 6 server
20101030:19:07:28|gp_dump-[INFO]:-Listening for messages from server on dbid 1 connection
20101030:19:07:28|gp_dump-[INFO]:-Successfully launched Greenplum Database backup on dbid 1 server
20101030:19:07:31|gp_dump-[INFO]:-backup succeeded for dbid 4 on host hadoop5
20101030:19:07:31|gp_dump-[INFO]:-All remote gp_dump_agent processes have began transactions in serializable isolation level
20101030:19:07:31|gp_dump-[INFO]:-Waiting for remote gp_dump_agent processes to obtain local locks on dumpable objects
20101030:19:07:31|gp_dump-[INFO]:-backup succeeded for dbid 6 on host hadoop6
20101030:19:07:31|gp_dump-[INFO]:-backup succeeded for dbid 3 on host hadoop4
20101030:19:07:31|gp_dump-[INFO]:-All remote gp_dump_agent processes have obtains the necessary locks
20101030:19:07:31|gp_dump-[INFO]:-Committing transaction on the master database, thereby releasing locks.
20101030:19:07:31|gp_dump-[INFO]:-Waiting for all remote gp_dump_agent programs to finish.
20101030:19:07:31|gp_dump-[INFO]:-backup succeeded for dbid 7 on host hadoop6
20101030:19:07:31|gp_dump-[INFO]:-backup succeeded for dbid 5 on host hadoop5
20101030:19:07:31|gp_dump-[INFO]:-backup succeeded for dbid 2 on host hadoop4
20101030:19:07:31|gp_dump-[INFO]:-backup succeeded for dbid 1 on host hadoop4
20101030:19:07:31|gp_dump-[INFO]:-All remote gp_dump_agent programs are finished.
20101030:19:07:31|gp_dump-[INFO]:-Report results also written to /home/gpadmin1/cxf/gpdb_p1/gp-1/gp_dump_20101030190728.rpt.

Greenplum Database Backup Report
Timestamp Key: 20101030190728
gp_dump Command Line: --gp-d=/home/gpadmin1/backups aligputf8
Pass through Command Line Options: None
Compression Program: None

Individual Results
        segment 5 (dbid 7) Host hadoop6 Port 40001 Database aligputf8 BackupFile /home/gpadmin1/backups/gp_dump_0_7_20101030190728: Succeeded
        segment 4 (dbid 6) Host hadoop6 Port 40000 Database aligputf8 BackupFile /home/gpadmin1/backups/gp_dump_0_6_20101030190728: Succeeded
        segment 3 (dbid 5) Host hadoop5 Port 40001 Database aligputf8 BackupFile /home/gpadmin1/backups/gp_dump_0_5_20101030190728: Succeeded
        segment 2 (dbid 4) Host hadoop5 Port 40000 Database aligputf8 BackupFile /home/gpadmin1/backups/gp_dump_0_4_20101030190728: Succeeded
        segment 1 (dbid 3) Host hadoop4 Port 40001 Database aligputf8 BackupFile /home/gpadmin1/backups/gp_dump_0_3_20101030190728: Succeeded
        segment 0 (dbid 2) Host hadoop4 Port 40000 Database aligputf8 BackupFile /home/gpadmin1/backups/gp_dump_0_2_20101030190728: Succeeded
        Master (dbid 1) Host hadoop4 Port 5432 Database aligputf8 BackupFile /home/gpadmin1/backups/gp_dump_1_1_20101030190728: Succeeded

gp_dump utility finished successfully.

//到此为止备份成功了，我们可以看一下目录/home/gpadmin1/backups下生成的文件
[gpadmin1@hadoop4 backups]$ ls
gp_cdatabase_1_1_20101030190728  gp_dump_0_3_20101030190728  gp_dump_status_0_2_20101030190728  gp_dump_status_1_1_20101030190728
gp_dump_0_2_20101030190728       gp_dump_1_1_20101030190728  gp_dump_status_0_3_20101030190728
[gpadmin1@hadoop4 backups]$ psql
psql (8.2.14)
Type "help" for help.

aligputf8=# select * from t1;
 id
----
  1
  3
  2
(3 rows)

//现在把t1表删掉，一会进行恢复后看看结果
aligputf8=# drop table t1;
DROP TABLE
aligputf8=# select * from t1;
ERROR:  relation "t1" does not exist
LINE 1: select * from t1;
                      ^
aligputf8=# /q
[gpadmin1@hadoop4 backups]$ gp_restore --gp-k=20101030190728 --gp-d=/home/gpadmin1/backups -d aligputf8
20101030:19:09:11|gp_restore-[INFO]:-Analyzed command line options.
20101030:19:09:11|gp_restore-[INFO]:-Connecting to master segment on host localhost port 5432 database aligputf8.
20101030:19:09:11|gp_restore-[INFO]:-Reading Greenplum Database configuration info from master segment database.
20101030:19:09:11|gp_restore-[INFO]:-Preparing to restore the following segments:
20101030:19:09:11|gp_restore-[INFO]:-Segment 5 (dbid 7)
20101030:19:09:11|gp_restore-[INFO]:-Segment 4 (dbid 6)
20101030:19:09:11|gp_restore-[INFO]:-Segment 3 (dbid 5)
20101030:19:09:11|gp_restore-[INFO]:-Segment 2 (dbid 4)
20101030:19:09:11|gp_restore-[INFO]:-Segment 1 (dbid 3)
20101030:19:09:11|gp_restore-[INFO]:-Segment 0 (dbid 2)
20101030:19:09:11|gp_restore-[INFO]:-Master (dbid 1)
20101030:19:09:11|gp_restore-[INFO]:-Starting to restore the master database.
20101030:19:09:11|gp_restore-[INFO]:-Creating thread to restore master database: host hadoop4 port 5432 database aligputf8
20101030:19:09:11|gp_restore-[INFO]:-Listening for messages from dbid 1 server (source) for dbid 1 restore
20101030:19:09:11|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 1 to restore dbid 1
20101030:19:09:13|gp_restore-[INFO]:-restore started for source dbid 1, target dbid 1 on host hadoop4
20101030:19:09:13|gp_restore-[ERROR]:-restore failed for source dbid 1, target dbid 1 on host hadoop4
20101030:19:09:13|gp_restore-[ERROR]:-see error report for details
20101030:19:09:13|gp_restore-[INFO]:-Report results also written to /home/gpadmin1/cxf/gpdb_p1/gp-1/gp_restore_20101030190728.rpt.

Greenplum Database Restore Report
Timestamp Key: 20101030190728
gp_restore Command Line: --gp-k=20101030190728 --gp-d=/home/gpadmin1/backups -d aligputf8
Pass through Command Line Options: None
Compression Program: None

Individual Results
        Restore of database "aligputf8" on Master database: Failed with error:
{psql:/home/gpadmin1/backups/gp_dump_1_1_20101030190728:40: ERROR:  relation "test" already exists
20101030:19:09:13|gp_restore_agent-[ERROR]:-psql finished abnormally with return code 3.
20101030:19:09:13|gp_restore_agent-[ERROR]:-Finished with errors
}

gp_restore  utility finished unsuccessfully with 1 failure.
//这里就要说一下了，失败的原因提示的很明显，因为有一个表test已经存在了。我在实验的过程中发现GP在恢复的时候如果遇到相同的对象，并不会覆盖它，而是会报错。当然，如果你在备份的时候指定-a参数，表明只备份数据，那么在恢复的时候即使存在同名对象也是没关系的。我们把test表删除了再恢复一下试试。
[gpadmin1@hadoop4 backups]$ psql
psql (8.2.14)
Type "help" for help.

aligputf8=# select * from test;
 a | b
---+---
(0 rows)

aligputf8=# select * from t1;
ERROR:  relation "t1" does not exist
LINE 1: select * from t1;
                      ^
aligputf8=# drop table cxf;
DROP TABLE
aligputf8=# /q
[gpadmin1@hadoop4 backups]$ gp_restore --gp-k=20101030190728 --gp-d=/home/gpadmin1/backups -d aligputf8
20101030:19:09:42|gp_restore-[INFO]:-Analyzed command line options.
20101030:19:09:42|gp_restore-[INFO]:-Connecting to master segment on host localhost port 5432 database aligputf8.
20101030:19:09:42|gp_restore-[INFO]:-Reading Greenplum Database configuration info from master segment database.
20101030:19:09:42|gp_restore-[INFO]:-Preparing to restore the following segments:
20101030:19:09:42|gp_restore-[INFO]:-Segment 5 (dbid 7)
20101030:19:09:42|gp_restore-[INFO]:-Segment 4 (dbid 6)
20101030:19:09:42|gp_restore-[INFO]:-Segment 3 (dbid 5)
20101030:19:09:42|gp_restore-[INFO]:-Segment 2 (dbid 4)
20101030:19:09:42|gp_restore-[INFO]:-Segment 1 (dbid 3)
20101030:19:09:42|gp_restore-[INFO]:-Segment 0 (dbid 2)
20101030:19:09:42|gp_restore-[INFO]:-Master (dbid 1)
20101030:19:09:42|gp_restore-[INFO]:-Starting to restore the master database.
20101030:19:09:42|gp_restore-[INFO]:-Creating thread to restore master database: host hadoop4 port 5432 database aligputf8
20101030:19:09:42|gp_restore-[INFO]:-Listening for messages from dbid 1 server (source) for dbid 1 restore
20101030:19:09:42|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 1 to restore dbid 1
20101030:19:09:44|gp_restore-[INFO]:-restore started for source dbid 1, target dbid 1 on host hadoop4
20101030:19:09:44|gp_restore-[INFO]:-restore succeeded for source dbid 1, target dbid 1 on host hadoop4
20101030:19:09:44|gp_restore-[INFO]:-Successfully restored master database: host hadoop4 port 5432 database aligputf8
20101030:19:09:44|gp_restore-[INFO]:-Creating thread to restore dbid 7 (hadoop6:40001) from backup file on dbid 7 (hadoop6:40001)
20101030:19:09:44|gp_restore-[INFO]:-Creating thread to restore dbid 6 (hadoop6:40000) from backup file on dbid 6 (hadoop6:40000)
20101030:19:09:44|gp_restore-[INFO]:-Creating thread to restore dbid 5 (hadoop5:40001) from backup file on dbid 5 (hadoop5:40001)
20101030:19:09:44|gp_restore-[INFO]:-Creating thread to restore dbid 4 (hadoop5:40000) from backup file on dbid 4 (hadoop5:40000)
20101030:19:09:44|gp_restore-[INFO]:-Creating thread to restore dbid 3 (hadoop4:40001) from backup file on dbid 3 (hadoop4:40001)
20101030:19:09:44|gp_restore-[INFO]:-Creating thread to restore dbid 2 (hadoop4:40000) from backup file on dbid 2 (hadoop4:40000)
20101030:19:09:44|gp_restore-[INFO]:-Waiting for all remote gp_restore_agent programs to finish.
20101030:19:09:44|gp_restore-[INFO]:-Listening for messages from dbid 3 server (source) for dbid 3 restore
20101030:19:09:44|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 3 to restore dbid 3
20101030:19:09:44|gp_restore-[INFO]:-Listening for messages from dbid 4 server (source) for dbid 4 restore
20101030:19:09:44|gp_restore-[INFO]:-Listening for messages from dbid 5 server (source) for dbid 5 restore
20101030:19:09:44|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 4 to restore dbid 4
20101030:19:09:44|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 5 to restore dbid 5
20101030:19:09:44|gp_restore-[INFO]:-Listening for messages from dbid 6 server (source) for dbid 6 restore
20101030:19:09:44|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 6 to restore dbid 6
20101030:19:09:44|gp_restore-[INFO]:-Listening for messages from dbid 7 server (source) for dbid 7 restore
20101030:19:09:44|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 7 to restore dbid 7
20101030:19:09:44|gp_restore-[INFO]:-Listening for messages from dbid 2 server (source) for dbid 2 restore
20101030:19:09:44|gp_restore-[INFO]:-Successfully launched Greenplum Database restore on dbid 2 to restore dbid 2
20101030:19:09:46|gp_restore-[INFO]:-restore started for source dbid 3, target dbid 3 on host hadoop4
20101030:19:09:46|gp_restore-[INFO]:-restore started for source dbid 7, target dbid 7 on host hadoop6
20101030:19:09:46|gp_restore-[INFO]:-restore started for source dbid 6, target dbid 6 on host hadoop6
20101030:19:09:46|gp_restore-[INFO]:-restore succeeded for source dbid 3, target dbid 3 on host hadoop4
20101030:19:09:46|gp_restore-[INFO]:-restore started for source dbid 2, target dbid 2 on host hadoop4
20101030:19:09:46|gp_restore-[INFO]:-restore succeeded for source dbid 6, target dbid 6 on host hadoop6
20101030:19:09:46|gp_restore-[INFO]:-restore succeeded for source dbid 7, target dbid 7 on host hadoop6
20101030:19:09:46|gp_restore-[INFO]:-restore started for source dbid 5, target dbid 5 on host hadoop5
20101030:19:09:46|gp_restore-[INFO]:-restore started for source dbid 4, target dbid 4 on host hadoop5
20101030:19:09:46|gp_restore-[INFO]:-restore succeeded for source dbid 2, target dbid 2 on host hadoop4
20101030:19:09:46|gp_restore-[INFO]:-restore succeeded for source dbid 5, target dbid 5 on host hadoop5
20101030:19:09:46|gp_restore-[INFO]:-restore succeeded for source dbid 4, target dbid 4 on host hadoop5
20101030:19:09:46|gp_restore-[INFO]:-All remote gp_restore_agent programs are finished.
20101030:19:09:46|gp_restore-[INFO]:-updating Append Only table statistics
20101030:19:09:46|gp_restore-[INFO]:-Report results also written to /home/gpadmin1/cxf/gpdb_p1/gp-1/gp_restore_20101030190728.rpt.

Greenplum Database Restore Report
Timestamp Key: 20101030190728
gp_restore Command Line: --gp-k=20101030190728 --gp-d=/home/gpadmin1/backups -d aligputf8
Pass through Command Line Options: None
Compression Program: None

Individual Results
        Restore of aligputf8 on dbid 1 (hadoop4:5432) from /home/gpadmin1/backups/gp_dump_1_1_20101030190728: Succeeded
        Restore of aligputf8 on dbid 7 (hadoop6:40001) from /home/gpadmin1/backups/gp_dump_0_7_20101030190728: Succeeded
        Restore of aligputf8 on dbid 6 (hadoop6:40000) from /home/gpadmin1/backups/gp_dump_0_6_20101030190728: Succeeded
        Restore of aligputf8 on dbid 5 (hadoop5:40001) from /home/gpadmin1/backups/gp_dump_0_5_20101030190728: Succeeded
        Restore of aligputf8 on dbid 4 (hadoop5:40000) from /home/gpadmin1/backups/gp_dump_0_4_20101030190728: Succeeded
        Restore of aligputf8 on dbid 3 (hadoop4:40001) from /home/gpadmin1/backups/gp_dump_0_3_20101030190728: Succeeded
        Restore of aligputf8 on dbid 2 (hadoop4:40000) from /home/gpadmin1/backups/gp_dump_0_2_20101030190728: Succeeded

gp_restore  utility finished successfully.

//好了，恢复成功了。
[gpadmin1@hadoop4 backups]$ psql
psql (8.2.14)
Type "help" for help.

aligputf8=# select * from t1;
 id
----
  3
  2
  1
(3 rows)

aligputf8=#

//我们可以在看一下gp_restore做了些什么事情，文档上讲的很清楚
The gp_restore utility performs the following actions:
On the master host

• Creates the user database schema(s) using the gp_dump_1_<dbid>_<timestamp> SQL file created by gp_dump.
• Creates a log file in the master data directory named gp_restore_status_1_<dbid>_<timestamp>.
• gp_restore launches a gp_restore_agent for each segment instance to be restored. gp_restore_agent processes run on the segment hosts and report status back to the gp_restore process running on the master host.

On the segment hosts

• Restores the user data for each segment instance using the gp_dump_0_<dbid>_<timestamp> files created by gp_dump. Each segment instance on a host (primary and mirror instances) are restored.
• Creates a log file for each segment instance named gp_restore_status_0_<dbid>_<timestamp>.

Note that the 14 digit timestamp is the number that uniquely identifies the backup job to be restored, and is part of the filename for each dump file created by a gp_dump operation. This timestamp must be passed to the gp_restore utility when restoring a Greenplum database

 

//可以验证一下
[gpadmin1@hadoop4 backups]$ ls
gp_cdatabase_1_1_20101030190728  gp_dump_status_0_2_20101030190728     gp_restore_status_0_3_20101030190728
gp_dump_0_2_20101030190728       gp_dump_status_0_3_20101030190728     gp_restore_status_1_1_20101030190728
gp_dump_0_3_20101030190728       gp_dump_status_1_1_20101030190728
gp_dump_1_1_20101030190728       gp_restore_status_0_2_20101030190728