【磁盘打满】xlog不被回收，发现pgdata目录被占满。

[sanyue (喃喃)]

数据库的版本为openGauss 6.0.1 build db72a150

目前是没有备，只是以主启动

执行查询语句

-- 执行时间越早，运行越久，排在前面

SELECT
pid,
sessionid,
datname AS database_name,
usename AS username,
client_addr AS client_address,
state,
query_start,
now() - query_start AS duration,
query
FROM pg_stat_activity
WHERE state <> ‘idle’
AND query_start IS NOT NULL
ORDER BY query_start ASC;

可以发现WLM一直活跃，而且会占用大量的cpu资源，根据资料只有它停止时才会进行回收。
WLM fetch collect info from data nodes。不过目前只有单个primary，其备节点不可达。

在issue里看到类似的问题，不过查看复制槽也都是空的

还有啥需要提供的请留言，会第一时间反馈，感谢大家提供帮助。

[openGauss_Assistant]

答案内容由AI生成，仅供参考：

总结与建议

项目	内容
根本原因推测	WLM 长时间运行任务卡住系统资源，阻碍 checkpoint 推进，间接导致 xlog 无法回收
主要解决措施	终止长任务、手动 CHECKPOINT、检查归档配置
后续优化建议
1. 升级到 openGauss 6.0.2 或更高版本，修复已知 bug；
2. 避免在单机模式下运行集群级监控任务（如 WLM 跨节点采集）；
3. 设置合理的归档和保留策略；
4. 定期巡检 pg_stat_activity 中的长事务；
5. 配置磁盘空间告警（建议 >80% 触发警告）

点击此处查看详细分析解答

openGauss 6.0.1 主库 xlog 不回收导致磁盘打满问题分析与解决方案

根据您提供的详细信息，当前数据库版本为 openGauss 6.0.1 build db72a150，运行在单节点主库模式（无备库），出现 xlog 日志不回收、pgdata 目录被占满 的问题。以下基于上下文信息进行系统性分析并提供解决方案。

---

问题诊断分析

1. 数据库状态确认

local_role             : Primary
db_state               : Normal

说明当前数据库运行正常，处于主库模式，且未感知到异常。

2. 复制槽与备库状态检查

SELECT * FROM pg_stat_replication;        -- 无发送者信息
SELECT * FROM pg_replication_slots;       -- 无复制槽存在

结果显示：

• 没有活跃的流复制连接；
• 没有配置逻辑或物理复制槽。

这排除了 因备库宕机或复制延迟导致 xlog 无法回收 的常见原因。

---

3. 关键线索：WLM 长时间运行任务

从 pg_stat_activity 查询结果中发现一个关键线索：

字段	值
PID	139987655263808
Query	WLM fetch collect info from data nodes
Duration	已运行超过 4 天
State	active

这个任务是 WLM（Workload Manager） 在尝试从“数据节点”收集信息，但当前为 单机部署，并无其他数据节点。

可能影响：

• WLM 的某些内部机制可能依赖于集群环境；
• 若该任务长时间挂起，可能间接影响事务状态推进、检查点生成或 XLog 清理线程；
• 在部分 openGauss 版本中，长时间未完成的内部任务可能会阻塞 checkpoint 推进，从而阻止 WAL（xlog）文件的回收。

---

4. 为何 xlog 不被回收？

尽管无备库和复制槽，理论上 xlog 应该可以正常回收，但在 openGauss 中，以下因素仍可能导致 xlog 堆积：

可能原因	是否符合当前场景
备库宕机或网络不通	当前无备库，排除
逻辑复制槽未推进	查询显示无复制槽，排除
checkpoint 未及时触发或卡住	有可能，尤其是存在长事务或内部任务
WAL 归档失败（archive_mode=on 但路径异常）	需进一步确认归档配置
存在未结束的事务或资源持有者	高风险：WLM 任务已运行 4 天
内部任务阻塞资源回收流程	非常可能，特别是 WLM 长时间运行

---

解决方案建议

第一步：终止长期运行的 WLM 任务

该任务极可能是导致系统资源占用、检查点无法推进的关键根源。

执行命令终止会话：

-- 使用 PID 终止长时间运行的任务
SELECT pg_terminate_backend(139987655263808);

建议在低峰期操作，并确保不影响业务。

观察效果：

• 检查 pg_stat_activity 是否消失；
• 查看系统 CPU 使用率是否下降；
• 观察后续是否开始自动清理 xlog 文件。

---

第二步：手动触发检查点，促进 xlog 回收

-- 强制执行一次完整检查点
CHECKPOINT;

检查点是 WAL 回收的前提条件之一。成功执行后，系统将更新 control_file 中的 checkpoint_loc，允许后续进程回收旧的日志文件。

建议每小时执行一次，直到 xlog 开始正常回收。

---

第三步：检查并清理归档配置（如启用）

查看是否开启了归档模式但路径不可写：

SHOW archive_mode;
SHOW archive_command;

如果 archive_mode = on，但归档命令失败（如路径不存在、权限不足），会导致 WAL 文件保留在 pg_xlog 目录中。

临时解决方案：

1. 禁用归档模式（仅限紧急情况）

   修改 postgresql.conf：

   archive_mode = off
   

2. 重启数据库或 reload 配置

   gs_ctl reload -D $PGDATA
   

3. 重启后再次执行 CHECKPOINT

注意：关闭归档会丢失 PITR（时间点恢复）能力，请评估风险。

---

第四步：检查磁盘空间与阈值参数

若磁盘使用率过高（接近 80%），openGauss 可能进入保护模式，暂停某些清理行为。

检查磁盘使用情况：

df -Th $PGDATA

调整 xlog 保留策略（可选）：

在 postgresql.conf 中增加或修改：

# 限制 xlog 最大保留大小（例如 100GB）
max_size_for_xlog_prune = 100GB

# 启用自动修剪
enable_xlog_prune = on

此参数可在主库无备时防止 xlog 无限增长。

---

第五步：监控 xlog 回收情况

观察 pg_xlog（或 pg_wal）目录变化：

# 查看 xlog 文件数量和总大小
ls -lt $PGDATA/pg_xlog/ | wc -l
du -sh $PGDATA/pg_xlog/

# 查看最近是否有清理日志
grep "attempting to remove WAL" $PGDATA/pg_log/*.log

---

总结与建议

项目	内容
根本原因推测	WLM 长时间运行任务卡住系统资源，阻碍 checkpoint 推进，间接导致 xlog 无法回收
主要解决措施	终止长任务、手动 CHECKPOINT、检查归档配置
后续优化建议
1. 升级到 openGauss 6.0.2 或更高版本，修复已知 bug；
2. 避免在单机模式下运行集群级监控任务（如 WLM 跨节点采集）；
3. 设置合理的归档和保留策略；
4. 定期巡检 pg_stat_activity 中的长事务；
5. 配置磁盘空间告警（建议 >80% 触发警告）

---

补充信息需求（如有需要请反馈）

为了更精准定位问题，建议补充以下内容：

1. postgresql.conf 中 archive_mode, archive_command, wal_keep_segments, checkpoint_timeout 等配置；
2. $PGDATA/pg_log/ 中最近的日志片段（搜索 WAL, checkpoint, flood）；
3. df -Th 输出，确认磁盘剩余空间；
4. 是否曾配置过备库后断开？（可能存在残留元数据）

---

如上述操作后仍无效，可考虑使用 pg_resetxlog -f（ 危险操作，可能导致数据不一致）作为最后手段，但仅限备份后且接受数据丢失风险时使用。

如需进一步协助，请提供日志片段。感谢支持！

[sanyue (喃喃)]

postgresql.conf 中 archive_mode = on 。archive_command = ‘/bin/date’。这里为了确保必定回收，我们直接搞了一个肯定运行成功的命令。目录也是对的，目前就有且只有这一个环境发现了该故障。
[mccuap@localhost ~]$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs tmpfs 15G 205M 15G 2% /dev/shm
tmpfs tmpfs 5.8G 25M 5.8G 1% /run
tmpfs tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
/dev/mapper/openeuler-root ext4 69G 1.8G 64G 3% /
tmpfs tmpfs 15G 19M 15G 1% /tmp
/dev/sda1 ext4 974M 145M 762M 16% /boot
/dev/mapper/openeuler-home ext4 316G 271G 29G 91% /home
从安装就没有配置过备库，不过存在断电重启的情况。 pg_log目录好像没有

[sanyue (喃喃)]

#max_size_for_xlog_prune = 2147483647  # xlog keep for the wal size less than max_xlog_size when the enable_xlog_prune is on
目前找了大佬帮忙看，看来是这个参数没有配置，且该环境没有启动备。暂时调整为20G，再观察看看。