修改GP系统表修复standby master

本是古典何须时尚 2022-05-14 12:24 240阅读 0赞

# 事件缘由： #

客户要求开发greenplum master高可用脚本，要实现master宕机的情况下，standby master被激活，接管业务。

但是在测试的过程中master切来切去，切乱了。

两个节点都是master，都能读写数据库。。。

即便杀掉第一个节点的master的进程，然后在第二个节点使用gpinitstandby -n 以启动的standby master的方式启动第一个节点的master，期望第一个节点的master启动后自动识别为standby master，从而不能连接以及读写数据库。但是发现第一个节点每次都是以正常模式启动，并且可以读写数据库。。。

原因是standby master节点$MASTER\_DATA\_DIRECTORY目录下的recovery.conf文件丢失，从而该节点不知道自己是standby master，不会从另外一个节点复制master信息。。。

**由此可见greenplum的master节点很容易脑裂！！！**

为了解决这一问题，需要修改greenplum的系统表，将其中一个master节点删除，然后重新创建standby master。

原理：

只启动greenplum的master节点，以utility模式连接到数据库，修改系统表，删除系统表中与standby master相关的信息（包括文件空间）。

具体操作如下：

#将数据库关闭（需要检查另一个master是否也关闭）
    gpstop -M fast
    
    #将数据库启动到维护模式：
    gpstart -m
    
    #使用utility模式连接数据库：
    PGOPTIONS='-c gp_session_role=utility' psql databasename
    
    #在psql中设置system catalog可以编辑：
    set allow_system_table_mods=DML;
    
    #在psql中删除gp_segment_configuration中standby master的记录：
    delete from gp_segment_configuration where content=-1 and role='m';
    
    #删除文件空间中关于另一个master的文件空间记录
    delete from pg_filespace_entry 
    where fselocation=‘/home/kaadmin/data/master/kaseg-1’ 
      and fsedbid=20;
    
    #停止数据库维护模式：
    gpstop -m
    
    #重新启动数据库
    gpstart -a
    
    #重新创建standby master（创建前先将另一个master的数据文件夹删除或改名）
    gpinitstandby -s remote_hostname

重建standby master之后，standby master节点的recovery.conf文件恢复正常。