内容接上一篇文章（https://blog.51cto.com/lee90/2371858），本文的实验拓扑等各种架构都和上一篇一致。
GP实验：Master节点宕掉
1、 在mdw节点执行：
gpstop -a -m 在mdw节点执行这个操作，模拟master节点宕机
此外，还有卸载vip的操作，这里忽略了
2、 在sdw3节点执行：
gpactivatestandby -a -d //home/gpadmin/gpdata/gpmaster/gpseg-1 提升为Master角色
此外，还有绑定vip的操作，这里忽略了
3、 指定新的standby节点
这里我们这里指定原先的master为新的standby节点。
需要先删除掉原先master节点的数据文件，然后重新执行下初始化standby节点即可。
在mdw上执行：
su - gpadmin
rm -fr /home/gpadmin/gpdata/gpmaster/*
在sdw3上执行:
gpinitstandby -s mdw 需要人工输入Y，【或者 gpinitstandby -a -s mdw 自动yes处理】
GP实验：Standby节点宕掉
standby节点宕掉的话，处理比较简单。直接删除数据重新初始化即可。
当standby宕机时候，通过 gpstate 和 gpstate -f 看到的如下：
修复方法：
在新的主节点依次执行：
gpinitstandby -r -a 删除故障的standby节点
gpinitstandby -a -s ${这里写宕机的standby节点主机名}
gpstate -f 检查standby 的配置信息
GP实验：segment节点宕掉
当一个primary segment节点故障，那么它所对应的mirror segment节点会接替primary的状态，继续保证整个集群的数据完整性
当一个mirror segment节点出现故障，它不会影响整个集群的可用性，但是需要尽快修复，保证所有的primary segment都有备份
如果primary segment 和 它所对应的mirror segment 节点都出现故障，那么greenplum认为集群数据不完整，整个集群将不再提供服务，直到primary segment 或 mirror segment恢复
修复segment节点，需要重启greenplum集群
primary segment节点和mirror segment节点的故障修复方式是一样的，这里以mirror节点故障为例
关闭一个mirror节点
sdw2 43000
[gpadmin@dw-greenplum-2 ~]$ /opt/greenplum/greenplum-db-5.16.0/bin/pg_ctl stop -D /home/gpadmin/gpdata/gpdatam1/gpseg4
waiting for server to shut down.... done
server stopped
--------master节点执行-------
[gpadmin@dw-greenplum-1 gpmaster]$ gpstate -m 【gpstate命令也行】
[gpadmin@dw-greenplum-1 gpmaster]$ gpstate -e
关闭整个greenplum集群
[gpadmin@dw-greenplum-1 gpmaster]$ gpstop -a -M fast
以restricted方式启动数据库
[gpadmin@dw-greenplum-1 gpmaster]$ gpstart -a -R
开始修复故障节点
[gpadmin@dw-greenplum-1 gpmaster]$ gprecoverseg -a
注意：
如果不用-a参数的话，可以分2步骤进行恢复。
step1、gprecoverseg -o ./recov 会在当前目录生成一个recov文件，里面包含了要恢复的节点信息，类似如下：
step2、gprecoverseg -i ./recov 使用恢复配置文件恢复节点
检查集群修复状态
[gpadmin@dw-greenplum-1 gpmaster]$ gpstate -m
注意：需要一直等到Data Status 这个属性全部都是Synchronized即可进行下一步操作
重启greenplum集群
[gpadmin@dw-greenplum-1 gpmaster]$ gpstop -a -r
TIPS：如果集群出现过primary和Mirror节点的切换，则最好再执行下下面的命令：
gprecoverseg -r 执行这步操作的原因：如果主节点down了，mirror节点接管后，会造成部分节点负担过重
