Greenplum是一款MPP（大规模并行处理）数据库。正常来说，依据Greenplum的使用特点，每天正常的访问数据库，数据库正常的写日志，是不会出现日志很快占满磁盘空间的情况的。
凡事都有个但是，这里面存在几个特殊情况：
1.长年累月的运行，时间长了难免积少成多，导致日志文件积压的比较多；尤其是Master节点通常不会配置太多的磁盘空间，这一点更要注意；
2.非正常使用MPP数据库，这里指的是没有按照推荐的方式使用，比如：数据入库大量采用单条insert。那么Master节点的日志肯定会剧增的，我就在一个客户现场遇到过，开发人员直接将Kafka的消费写成单挑insert通过Master插入，一个月就把200GB的空间占满了。
那么如果木已成舟怎么办？
我们只能想办法规避这种日志频繁写入把空间占满的情况，总结来看，有两种方法：
1.通过定时脚本定期清理设定时间之前的日志文件，可以随意定义时长，可以参考我5年前写的以天为单位的清理脚本
#!/bin/bash
# start time
start_time=$(date)
echo "-------- Start time is $start_time --------"
start_seconds=$(date +%s)
# delete log files
find /data/master/gpseg-1/pg_log -mtime +90 -name "*.csv" -exec rm -rf {} \;
find /seg0/gpseg0/pg_log -mtime +90 -name "*.csv" -exec rm -rf {} \;
find /seg1/gpseg1/pg_log -mtime +90 -name "*.csv" -exec rm -rf {} \;
find /seg2/gpseg2/pg_log -mtime +90 -name "*.csv" -exec rm -rf {} \;
find /seg3/gpseg3/pg_log -mtime +90 -name "*.csv" -exec rm -rf {} \;
# end time
end_time=$(date)
echo "-------- End time is $end_time --------"
end_seconds=$(date +%s)
diff=$((end_seconds - start_seconds))
echo "Total $diff seconds."
echo ""
echo ""该脚本使用需要注意几个点：
- 可以灵活定义日志清理时间，通过修改脚本中的数字90即可；
- 需要对应每台机器上的日志位置，修改日志路径；
- 在安全性要求较高的系统中，不能使用，因为脚本中有rm -rf操作。
2.通过修改节点的postgresql.conf配置文件，配置一种周期性覆盖的逻辑，以下是一个简单的例子，默认保留七天的文件，超过七天会复写：
# 修改Master节点上的postgresql.conf文件，增加以下四行内容
log_filename = 'greenplum-%a.log' #日志名称，以周几为单位
log_truncate_on_rotation = on #开启覆盖功能
log_rotation_age = 1d #以1天位单位生成1个文件
log_rotation_size = 0
根据上面设置后，重启数据库，查看pg_log下的日志文件，如下（我已经运行了一段时间了，所以有7个文件，正常刚修改完配置只有一个文件）：
-rw------- 1 gpadmin1 gpadmin 23415 Sep 4 18:39 greenplum-Fri.csv
-rw------- 1 gpadmin1 gpadmin 955862 Sep 8 00:30 greenplum-Mon.csv
-rw------- 1 gpadmin1 gpadmin 19907 Sep 5 23:59 greenplum-Sat.csv
-rw------- 1 gpadmin1 gpadmin 4354 Sep 6 09:35 greenplum-Sun.csv
-rw------- 1 gpadmin1 gpadmin 182596 Sep 3 21:57 greenplum-Thu.csv
-rw------- 1 gpadmin1 gpadmin 12054 Sep 8 08:09 greenplum-Tue.csv
-rw------- 1 gpadmin1 gpadmin 17619 Sep 23 17:41 greenplum-Wed.csv
-rw------- 1 gpadmin1 gpadmin 142663 Sep 23 15:16 startup.log该操作也需要注意几个点：
- 如果Master的日志增长过快，可以单独修改Master，如上面的例子；
- 如果整体增长都很快，需要修改所有节点的postgresql.conf文件；
- 如果对日志存储有长期要求，这种复写的方式显然不行，需要扩充磁盘空间或将日志定期移走；
- 配置修改后，需要重启数据库。
End~
本文从CSDN（点击查看原文）转载而来。不代表烟海拾贝立场，如若转载，请注明出处：https://somirror.com/3666.html
