采用非常规方法（非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的作用，为恢复数据库打开新的思路。

原文：https://blog.csdn.net/aabc012/article/details/48280983

转载于:https://www.cnblogs.com/xibuhaohao/p/11133832.html