oracle 磁盘读写100,greenplum集群某台机器磁盘占用100%处理方式

一、问题描述

使用gpfdist往集群中导入大量数据， 一段时间后连接退出，集群无法连接

二、问题定位

使用如下命令查看：

gpstate -s

mdw-1:gpadmin-[INFO]:-Segment Info

mdw-1:gpadmin-[INFO]:- Hostname = sdw-1mdw-1:gpadmin-[INFO]:- Address = sdw-1mdw-1:gpadmin-[INFO]:- Datadir = /home/mirror/gpseg2

mdw-1:gpadmin-[INFO]:- Port = 50000mdw-1:gpadmin-[INFO]:-Mirroring Info

mdw-1:gpadmin-[INFO]:- Current role =Mirror

mdw-1:gpadmin-[INFO]:- Preferred role =Mirror

mdw-1:gpadmin-[WARNING]:- Mirror status = Out of Sync <<<<<<<

mdw-1:gpadmin-[INFO]:- PID = 10227mdw-1:gpadmin-[WARNING]:- Configuration reports status as = Down <<<<<<<

连接到相应机器，查看磁盘状况：

说明此时磁盘占用满了,无法启动的问题就在这里了

三、问题解决

处理这种情况有如下几种方式：

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