采用非常规方法（非gprecoverseg) 恢复greenplum数据库

greenplum数据库中mirror的作用就是作为primary的备份存在。那么恢复down掉的mirror或primary时，是否可以直接复制文件从primary或mirror到对应的mirror或primary来启动数据库，而不采用gprecoverseg呢？答案是肯定的。下面将讨论其中需要涉及的相关文件以及会出现的问题。

1，最简单的情况-某个mirror在down掉后，数据库没有出现数据修改操作的情况，此时进行恢复。

此时，该mirror和对应的primary记录数据的文件base是一样的。

pg_xlog是PostgreSQL的事务日志，包含几个二进制文件，每个文件固定大小为64MB，并不断重复使用，记录关于最近事务的数据。

greenplum在启动时正是通过对比primary和mirror的pg_xlog来判断它们是否处于同步状态，那么可以通过复制down掉的mirror对应的primary上的pg_xlog到该mirror上来"骗"过数据库启动时,master对他们的对比检查。另外还需要修改gp_segment_configuration中这一对实例的状态到正常，否则master还是会判断该mirror就是down掉了。

操作示例说明：

--现在content=0的mirror是'd'。

testDB=# 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 | mdw | mdw | |

3 | 1 | p | p | s | u | 40000 | sdw2 | sdw2 | 41000 |

5 | 1 | m | m | s | u | 50000 | sdw1 | sdw1 | 51000 |

2 | 0 | p | p | c | u | 40000 | sdw1 | sdw1 | 41000 |

4 | 0 | m | m | s | d | 50000 | sdw2 | sdw2 | 51000 |

--停掉数据库。

[gpadmin@mdw ~]$ gpstop -a

--将content=0的primary上的pg_xlog传输到目标节点机上。

[gpadmin@sdw1 gpseg0]$ scp -r pg_xlog/ gpadmin@sdw2:/data1/mirror

000000010000000200000014 100% 64MB 64.0MB/s 00:01

000000010000000200000015 100% 64MB 64.0MB/s 00:01

000000010000000200000016 100% 64MB 32.0MB/s 00:02

000000010000000200000017 100% 64MB 64.0MB/s 00:01

000000010000000200000018 100% 64MB 64.0MB/s 00:01

000000010000000200000019 100% 64MB 64.0MB/s 00:01

00000001000000020000001A 100% 64MB 64.0MB/s 00:01

00000001000000020000001B 100% 64MB 64.0MB/s 00:01

00000001000000020000001C 100% 64MB 32.0MB/s 00:02

00000001000000020000001D 100% 64MB 64.0MB/s 00:00

--用传输过来的pg_xlog覆盖该mirror上的pg_xlog。

[gpadmin@sdw2 mirror]$ cp -r pg_xlog/ gpseg0/

[gpadmin@sdw2 mirror]$ rm -rf pg_xlog/

--修改gp_segment_configuration中这一对实例的状态到正常。

[gpadmin@mdw ~]$ gpstart -m

[gpadmin@mdw ~]$ PGOPTIONS="-cgp_session_role=utility" psql

psql (8.2.15)

Type "help" for help.

testDB=# set allow_system_table_mods='dml';

testDB=# update gp_segment_configuration set mode='s' where dbid=2;

UPDATE 1

testDB=# update gp_segment_configuration set status='u' where dbid=4;

UPDATE 1

testDB=# 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 | mdw | mdw | |

3 | 1 | p | p | s | u | 40000 | sdw2 | sdw2 | 41000 |

5 | 1 | m | m | s | u | 50000 | sdw1 | sdw1 | 51000 |

2 | 0 | p | p | s | u | 40000 | sdw1 | sdw1 | 41000 |

4 | 0 | m | m | s | u | 50000 | sdw2 | sdw2 | 51000 |

(5 rows)

[gpadmin@mdw ~]$ gpstop -m

[gpadmin@mdw ~]$ gpstart -a

20150907:23:19:24:013031 gpstart:mdw:gpadmin-[INFO]:-Starting gpstart with args: -a

20150907:23:19:24:013031 gpstart:mdw:gpadmin-[INFO]:-Gathering information and validating the environment...

20150907:23:19:24:013031 gpstart:mdw:gpadmin-[INFO]:-Greenplum Binary Version: 'postgres (Greenplum Database) 4.3.5.1 build 1'

20150907:23:19:24:013031 gpstart:mdw:gpadmin-[INFO]:-Greenplum Catalog Version: '201310150'

20150907:23:19:24:013031 gpstart:mdw:gpadmin-[INFO]:-Starting Master instance in admin mode

20150907:23:19:25:013031 gpstart:mdw:gpadmin-[INFO]:-Obtaining Greenplum Master catalog information

20150907:23:19:25:013031 gpstart:mdw:gpadmin-[INFO]:-Obtaining Segment details from master...

20150907:23:19:25:013031 gpstart:mdw:gpadmin-[INFO]:-Setting new master era

20150907:23:19:25:013031 gpstart:mdw:gpadmin-[INFO]:-Master Started...

20150907:23:19:25:013031 gpstart:mdw:gpadmin-[INFO]:-Shutting down master

20150907:23:19:27:013031 gpstart:mdw:gpadmin-[INFO]:-Commencing parallel primary and mirror segment instance startup, please wait...

.......

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:-Process results...

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:-----------------------------------------------------

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:- Successful segment starts = 4

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:- Failed segment starts = 0

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:- Skipped segment starts (segments are marked down in configuration) = 0

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:-----------------------------------------------------

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:-

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:-Successfully started 4 of 4 segment instances

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:-----------------------------------------------------

20150907:23:19:34:013031 gpstart:mdw:gpadmin-[INFO]:-Starting Master instance mdw directory /data/master/gpseg-1

20150907:23:19:35:013031 gpstart:mdw:gpadmin-[INFO]:-Command pg_ctl reports Master mdw instance active

20150907:23:19:35:013031 gpstart:mdw:gpadmin-[INFO]:-No standby master configured. skipping...

20150907:23:19:35:013031 gpstart:mdw:gpadmin-[INFO]:-Database successfully started

--说明直接复制primary的文件pg_xlog至mirror，而不用gprecoverseg来恢复的方法是可行。

2, 某个mirror在down掉后，数据库出现了数据修改操作的情况，此时进行恢复。

如果此时还想用复制文件的方法进行恢复，就需要复制记录数据的base文件夹中的内容，如果不清楚具体那些文件不一样，可以复制覆盖整个base文件夹。

这里我主要想说明，数据库出现了数据修改操作，而没有复制base中的相应文件，只是复制pg_xlog来恢复启动数据库后引起的错误后果。

如果在content=0的mirror down掉后，创建了一个表syn_test，并插入了数据。

testDB=# create table syn_test(id int,name varchar(10)) distributed by (id);

CREATE TABLE

testDB=# insert into syn_test values(1,'ab'),(2,'dc'),(3,'dfs'),(4,'sfs');

INSERT 0 4

--该表的oid为890432，可以content=0的primary的base下找到刚建立的该文件，但在content=0的mirror的base下是没有该文件的。

testDB=# select oid,relname from pg_class where relname='syn_test';

oid | relname

--------+---------

890432 | syn_test

(1 row)

此时数据库出现了数据修改操作，但按上面第一节的方法，仅复制pg_xlog，并修改gp_segment_configuration来启动数据库。

此时增删改查都是正常的。

testDB=# select * from syn_test;

id | name

----+------

1 | ab

3 | dfs

2 | dc

4 | sfs

(4 rows)

testDB=# insert into syn_test values (5,'asfd'),(6,'fjdslj');

INSERT 0 2

testDB=# delete from syn_test where id in (5,6);

DELETE 2

testDB=# alter table syn_test alter name type char(10);

ALTER TABLE

但kill掉content=0的primary, 让content=0的mirror担当primary的角色时，任何操作都会出错。

testDB=# select * from syn_test;

ERROR: relation with OID 890432 does not exist (seg0 slice1 sdw2:50000 pid=10501)

--说明改表在该mirror中根本就不存在。

--在进行此种非正常操作时需谨慎判断数据的变化。

3，建立一个全新的gpseg0文件夹。

还有个问题就是将primary的整个gpseg0复制到对应的mirror的文件位置，建立一个全新的gpseg0文件夹，是否可行呢？

其实，直接复制文件夹也是可以的，但需要修改文件夹中记录关于实例信息的两个文件gp_dbid 和postmaster.opts，另外修改gp_segment_configuration中这一对实例的状态到正常还是必须的。

下面的对比可以看出primary和mirror中这两个文件的不同之处。

primary的gp_dbid

[gpadmin@sdw1 gpseg0]$ cat gp_dbid

# Greenplum Database identifier for this master/segment.

# Do not change the contents of this file.

dbid = 2

mirror的gp_dbid

[gpadmin@sdw2 gpseg0]$ cat gp_dbid

# Greenplum Database identifier for this master/segment.

# Do not change the contents of this file.

dbid = 4

primary的postmaster.opts

[gpadmin@sdw1 gpseg0]$ cat postmaster.opts

/usr/local/greenplum-db-4.3.5.1/bin/postgres "-D" "/data1/primary/gpseg0" "-p" "40000" "-b" "2" "-z" "2" "--silent-mode=true" "-i" "-M" "quiescent" "-C" "0"

mirror的postmaster.opts，需修改3 处

[gpadmin@sdw2 gpseg0]$ cat postmaster.opts

/usr/local/greenplum-db-4.3.5.1/bin/postgres "-D" "/data1/mirror/gpseg0" "-p" "50000" "-b" "4" "-z" "2" "--silent-mode=true" "-i" "-M" "quiescent" "-C" "0"

这里主要是理解pg_xlog的作用，为恢复数据库打开新的思路。