今天有一套环境因为网络调整，结果诺大的Greenplum集群，primary和mirror节点部分有了故障，假设有200个实例，100个segment,100个mirror，情况就是100个实例出现了问题（可能mirror已经宕机，可能mirror切换为primary，可能primary切换为mirror）刚好保证了100个实例能够正常承接业务。

比如你通过GPCC的方式看到下面的这种情况，你的内心应该是崩溃的。

    以下面的这个图为例，基本就是master是Greenplum节点，下面的PostgreSQL节点分别有多个segment组成，segment的角色分为primary和mirror,即每一个节点都是一个热备组合。

    这样来一铲子，或者网络的大的异常，那么整个集群中segment节点间的心跳就歇菜了。

    下面是问题发生时Greenplum节点抛出的日志信息：

2018-05-24 05:01:58.266841 CST,,,p42420,th972601120,,,,0,con2,,seg-1,,,,,"LOG","00000","FTS: primary (dbid=23) reported mirroring fault with mirror (dbid=124), mirror considered to be down.",,,,,,,0,,"ftsfilerep.c",358,

。。。

2018-05-24 05:01:58.266888 CST,,,p42420,th972601120,,,,0,con2,,seg-1,,,,,"LOG","00000","FTS: change state for segment (dbid=23, content=21) from ('u','p') to ('u','p')",,,,,,,0,,"fts.c",1157,

    可以从日志看到mirro发生了故障。

修复segment节点，Greenplum提供的工具集gprecoverseg还蛮不错，可以转储出一个列表recov，然后专门修复列表中的segment

$ gprecoverseg  -o ./recov

...

20180524:10:14:18:191458 gprecoverseg:xxxxx:gpadmin-[INFO]:-Configuration file output to ./recov successfully.

列表生成的信息如下：

$ less recov 

filespaceOrder=data2_sata_fsp

segment_51:41000:/data1/greenplum_data/gpdatam01/gpseg0

segment_51:41001:/data1/greenplum_data/gpdatam02/gpseg1

segment_51:41002:/data1/greenplum_data/gpdatam03/gpseg2

....

使用如下的方式开启恢复

gprecoverseg  -i ./recov 

整个过程GP的操作还是求稳，会逐个验证一遍segment的状态，保证要恢复的segment节点是down的状态，等都验证完成后，进入交互模式，你得确定要恢复才会开始。

修复完成后，segment节点就会开启同步了。

但是还是有不完善的地方，就是有12个节点的角色依然是有问题的。比如之前是primary,现在切换成了mirror,那么preferred role就是primary.

对于这种情况，还是gprecoverseg里面的-r选项就可以实现这个需求。

gprecoverseg -r

整个过程会持续一些时间，最后的结果还是喜人的。

这种场景如果自己练习，内心可能不会有什么波澜，假设这个业务很重要，而且需要快速恢复，你甚至都不能保证所有的操作100%有效，不会触发bug，想想小心脏都受不了啊。