问题现象
最近有一个之前搭的环境登不上了，好久没用想拿来测试的时候发现启动不了。启动时报错：[Errno 28] No space left on device
query也不行了，提示没有空间了。
查询磁盘使用情况 df -h ，果然100%
这个环境当时安装的是主备，看了下备库的服务器，发现不知道啥时候已经被删库了，安装用户都不在了。
问题定位
进一步排查主库服务器，发现opt目录下的空间最可疑。
[root@opengauss1 /]# du -lh –max-depth=1
根据经验直奔data/dn目录，果然就是这里 ，pg_xlog下面产生了过多日志文件。
看了下文件个数，有1500多个。
[root@opengauss1 pg_xlog]# ls -l |wc -l
1591
但是pg_xlog是WAL日志，是不能直接删除的。我们在另外空闲的空间下/tmp新建目录，再挪一部分xlog过去
[omm@opengauss1 ~]$ cd /tmp/
[omm@opengauss1 tmp]$ ll
total 0
-rw-r–r– 1 root root 0 Mar 22 11:40 ck_monitor.lock
drwxr-x— 2 root root 40 Sep 29 10:00 his-matrixagent_job
-rw-r–r– 1 root root 0 Mar 22 11:40 monitor.lock
dr-xr-x— 2 root root 40 May 27 2022 pub
drwx—— 3 root root 60 May 6 2022 systemd-private-ff4a118aad534bfe95b6b390fe984558-chronyd.service-Cy8Q8X
drwx—— 3 root root 60 May 6 2022 systemd-private-ff4a118aad534bfe95b6b390fe984558-systemd-logind.service-KrDeKX
[omm@opengauss1 tmp]$ mkdir xlog_mv_322
回到 pg_xlog目录 执行迁移
[omm@opengauss1 pg_xlog]$ ls -ltr | head -n 100 | awk \'{print \”mv \”$9 \” /tmp/xlog_mv_322/\”}\’ | sh
再尝试重新启动数据库。因为我的备库已经完全废弃了，只能指定以主库模型重启 加 -M primary参数。
[omm@opengauss1 pg_xlog]$ gs_ctl start -D /opt/huawei/install/data/dn/ -M primary
主库启动成功。登进去查看逻辑复制槽。
[omm@opengauss1 pg_xlog]$ gsql -d postgres -p 15400 -r
gsql ((openGauss 3.0.0 build 02c14696) compiled at 2022-04-01 18:12:19 commit 0 last mr )
NOTICE : The password has been expired, please change the password.
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type \”help\” for help.
openGauss=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn | dummy_standby
———–+——–+———–+——–+———-+——–+——+————–+————-+—————
dn_6002 | | physical | 0 | | f | | | 1/4C6B8F70 | f
(1 row)
删除失效逻辑复制槽
openGauss=# select * from pg_drop_replication_slot(\’dn_6002\’);
WARNING: replicationSlotMinLSN is InvalidXLogRecPtr!!!
WARNING: replicationSlotMaxLSN is InvalidXLogRecPtr!!!
pg_drop_replication_slot
————————–
(1 row)
openGauss=# select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn | dummy_standby
———–+——–+———–+——–+———-+——–+——+————–+————-+—————
(0 rows)
查看相关参数
openGauss=# show wal_keep_segments;
wal_keep_segments
——————-
16
(1 row)
openGauss=# show max_size_for_xlog_prune;
max_size_for_xlog_prune
————————-
2147483647kB
(1 row)
openGauss=# show enable_xlog_prune;
enable_xlog_prune
——————-
on
(1 row)
openGauss=# show archive_mode;
archive_mode
————–
off
(1 row)
openGauss=# \\q
综合看下来， max_size_for_xlog_prune参数的问题，它表示如果有备机断连且xlog日志大小大于此阈值，则回收日志。但是，默认值 给 的 太大了2048G，但是我这个环境只有40G，磁盘撑爆了。
解决办法
知道了问题，那么解决方法就是修改max_size_for_xlog_prune为4G，多余的日志 让DB自动清理。
[omm@opengauss1 pg_xlog]$ gs_guc reload -D /opt/huawei/install/data/dn/ -c \”max_size_for_xlog_prune=4194304\”
再去查看空间已经释放。
问题解决，主库又能继续坚持工作了。
总结
当归档或流复制发生异常时，事务日志会不断生成，如果默认值没修改，可能会造成磁盘撑爆，直接导致DB挂掉还起不来。遇到pg_xlog爆满时，先备份一部分pg_xlog日志到其他地方，删掉较早时间的日志，等有一定磁盘空间后再尝试启动数据库，然后设置合适的参数值，最后修复问题。
到此这篇关于openGauss数据库pg_xlog爆满问题解决的文章就介绍到这了,更多相关openGauss数据库pg_xlog爆满内容请搜索悠久资源以前的文章或继续浏览下面的相关文章希望大家以后多多支持悠久资源！
