Greenplum是一个比较健壮的数据库产品，所以常规使用过程中，鲜有问题出现。

通常集群出现问题都是外部环境导致的，比如磁盘空间满了导致集群hang住，或者 文件系统损坏导致文件丢失等。

今天社区的小伙伴在使用官方版本gpcc后，发现data目录特别大，然后强行卸载gpcc，最终由于一些未知的原因而导致集群重启失败了。这里说一下帮他定位问题的思路：

1.清理集群环境

首先上来要清理集群所有机器上的/tmp/.s.PG.xxx相关的socket文件，清理所有机器上的残留进程ps -ef | grep postgres，清理对应的postmaster.pid文件，否则集群启动会报错。

2.尝试启动集群

采用命令尝试启动集群，启动过程中，观察启动日志处于什么阶段，是在启动Master的时候失败，还是在启动Segment的时候失败。通常的启动命令为：

gpstart -a

如果你感觉并行启动没谱，或者是很难看日志，那可以使用如下命令，串行启动集群看看是在启动的哪一个阶段报错了：

gpstart -B 1 -t 3600 -v

3.观察日志定位具体原因

经过第二步的定位，我默认大家已经找到无法启动的位置了。这里就用今天的例子，来分析一下，社区小伙伴这个集群，是由于Master实例无法启动导致的。所以我接下来要去验证一下Master无法启动的具体原因，采用的命令为：

gpstart -m

该命令用于只启动Master节点，在启动过程中，到Master节点的pg_log目录下去看了一下日志记录，发现错误信息如下：

the database system is starting up, replayed record is 0/0.

默认情况下，重放日志记录不会在0/0位置，所以可能存在一些错误了。这时候，如果要修复Master有两种办法。

4.解决问题

上面定位到问题了，是因为Master节点拉不起来，这时候，要修复Master存在两种办法。如下：

1. 如果集群中已经配置了standby master，此时把master上的进程、tmp socket清理干净，然后直接激活standby master节点即可。后面原失败的master重装后，初始化为standby master再进行其他操作即可，这样成本和风险最低。（配合命令 gpactivestandby和gpstop、gpstart）
2. 如果没有配置standby，那只能通过pg_resetxlog来做了。

OK，大体思路是这样，大家感兴趣的多多留言、随时交流。