一、问题描述
使用gpfdist往集群中导入大量数据， 一段时间后连接退出，集群无法连接
二、问题定位
使用如下命令查看：
gpstate -s
mdw-:gpadmin-[INFO]:- Segment Info
mdw-:gpadmin-[INFO]:- Hostname = sdw-
mdw-:gpadmin-[INFO]:- Address = sdw-
mdw-:gpadmin-[INFO]:- Datadir = /home/mirror/gpseg2
mdw-:gpadmin-[INFO]:- Port =
mdw-:gpadmin-[INFO]:- Mirroring Info
mdw-:gpadmin-[INFO]:- Current role = Mirror
mdw-:gpadmin-[INFO]:- Preferred role = Mirror
mdw-:gpadmin-[WARNING]:- Mirror status = Out of Sync <<<<<<<<
mdw-:gpadmin-[INFO]:- Status
mdw-:gpadmin-[INFO]:- PID =
mdw-:gpadmin-[WARNING]:- Configuration reports status as = Down <<<<<<<<
mdw-:gpadmin-[WARNING]:- Segment status = Down in configuration <<<<<<<<
连接到相应机器，查看磁盘状况：
说明此时磁盘占用满了,无法启动的问题就在这里了
三、问题解决
处理这种情况有如下几种方式：
3.1 扩容磁盘
由于本人是将数据目录直接放在根目录下，可以通过添加一块新磁盘的方式直接扩容空间
3.2 清理文件
往往，线上的环境不会有足够的时间进行磁盘的扩容，甚至一些其他因素导致根本你就接触不到服务器。那么这时候只能进行文件的清除。
3.2.1 清理日志文件
系统长时间运行后，pg_log文件夹下日志文件会占用一定的空间，这里可以直接删除该目录下的文件，或者是备份到其他地方，让系统正常启动。
3.2.2 清理pg_xlog文件(慎重！慎重！)
该操作需要在数据库停机的情况下做。
在segment下，会有pg_xlog文件夹，这个文件夹里存储的是wal日志信息，记录事务信息，类似oracle的redo日志,数据在进入greenplum数据库前，都是先进入到该日志文件中，所以该文件非常重要，千万不能手工操作该目录下的文件，如果直接手工删除了该文件，数据库就无法启动。所以删除该文件要谨慎，可以使用该命令：pg_resetxlog 。只有在xlog占用了大量空间的情况下才考虑清理，否则不建议清理。操作步骤：
1）停止greenplum集群（或者是数据库已经由于磁盘空间不够而停止了）
2）使用pg_controldata命令
pg_controldata $segment_directory
......
Latest checkpoint's NextXID: 0/72023
Latest checkpoint's NextOID: 25175
......
这里$segment_directory是segment目录，也就是gpstate -s命令看到的Datadir的路径，如果找不到可以搜索pg_control，该文件所在的位置即为需要的目录位置，通过上述命令获取到标红的两处关键性信息
3）执行如下命令：
pg_resetxlog -o 25175 -x 72023 -f $segment_directory
注意，一般情况下pg_xlog 和 pg_clog 目录是不可以动的，除非是没有其他手段能让数据库起来，这里作为清理数据的最后手段，清理前也强烈建议把文件备份到其他目录，以防万一。
另外，以上命令需要数据库管理员账户执行，上述命令完成后，根据你的使用的空间大小，一般能够有不少的空间释放出来，可以让你的系统先起来。
由于任何原因导致pg_controldata不可用的时候，可以使用下面的方式人工计算出来相应的值：
4）启动greenplum集群
四、实践建议
1、清理xlog日志是在不得已的情况下才这么做，待集群正常启动后，需要谨慎验证数据的完整性
2、需要有自己的一套监控机制监控磁盘使用率，尽可能的避免磁盘使用100%的情况发生，一旦由于这种情况导致了集群崩溃，甚至丢失数据，可能是灾难性的
3、如果是由于误删了pg_logs的文件导致集群无法启动，也可以使用pg_resetxlog命令使集群恢复启动，但一定要谨慎验证数据的完整性
五、参考文章
https://blog.csdn.net/w1992wishes/article/details/82631240