openGauss数据库xlog目录满问题处理

openGauss 数据库 xlog 目录满问题处理

openGauss 数据库 xlog 满通常为以下几个原因：

1.主备状态不正常，存在网络问题，集群内有宕机的节点

2.xlog 保留数量过多

3.逻辑复制槽失效，且未及时清理

4.开启归档，但归档失败导致 xlog 不清理

首先，确认数据库状态

gs_om -t query

确认主备状态，是否存在宕机的节点。

查看是否存在 down，Standby Need repair(WAL)或者 unkown 的状态。

如果数据库状态不正常，xlog 目录 100%

需要手动移走一部分 xlog 后，检查数据库状态后将库拉起，并排查相关问题。

如果数据库状态正常，仅 xlog 目录大，则继续排查其他问题。

清理：

1.找一个空间大的目录

例如：

su - omm

cd /opengauss_bak

mkdir xlog_mv_0919

2.移走部分 xlog，到 xlog 路径下

cd /ogdata/data/dn1/pg_xlog

查看 xlog 数量,看是否 xlog 保留过多

ls | wc -l

！！！为了恢复环境，移动一小部分 xlog，其余等处理之后，自己清理

生成移动 xlog 语句，并检查（前 1000 条）

ls -ltr | head -n 1000 | awk '{print "mv "$9 " /opengauss_bak/xlog_mv_0919/"}'

3.#实际执行移动操作

ls -ltr | head -n 1000 | awk '{print "mv "$9 " /opengauss_bak/xlog_mv_0919/"}' | sh

4.移动之后 df -Th 看空间是否下来

5.gs_om -t query 查看数据库状态

如果不正常，需要先尝试拉起主数据库

gs_ctl start -D /ogdata/data/dn1

然后依次拉起备机数据库

gs_ctl start -D /ogdata/data/dn1 -M standby

备库拉不起来则先不处理，等找到 xlog 目录满源头后（例如主库删除失效逻辑复制后）,考虑做 build(先尝试增量不行再用增量）

gs_ctl build -D /ogdata/data/dn1 -b incremental

gs_ctl build -D /ogdata/data/dn1 -b full

6.登录主数据库查看逻辑复制槽状态，查看有无失效逻辑复制槽

select * from pg_replication_slots;

7.在主库删除失效逻辑复制槽

select * from pg_drop_replication_slot('aohdoasdaoiodiandoan');

---------aohdoasdaoiodiandoan为逻辑复制槽名字

删除失效的逻辑复制槽，主库和备库的 xlog 目录应该都会释放一部分空间

8.删除后 df -Th 看空间是否下来

9.参数调整

（1）查看 wal_keep_segments 参数，该参数为 Xlog 日志文件段数量,“pg_xlog”目录下保留事务日志文件的最小数目。

（2）查看 max_size_for_xlog_prune 参数，在 enable_xlog_prune 打开时生效，如果有备机断连且 xlog 日志大小大于此阈值，则回收日志。

根据实际状况，可进行修改。

（3）如果是 PG13 版本，可考虑开启 max_slot_wal_keep_size 参数，他是允许 replication slot 保留的 wal 文件的最大

大小，用于防止 wal 无限增大导致主库的文件系统空间被撑爆，设置该参数之后如果超过该参数值，PostgreSQL 将开始删除最

早的 WAL 文件。默认值是-1，-1 表示表示禁用本功能。单位是 MB。

10.检查归档模式是否开启

show archive_mode;

到归档目录下，看开启归档参数时，是否有归档。并检查归档空间，排除归档相关问题。