PG数据库wal日志空间异常

本文详细介绍了如何处理PostgreSQL数据库wal日志空间使用率达到97%的问题。首先检查wal相关参数,如max_wal_size、min_wal_size等,确认设置是否合理。接着排查可能导致wal日志无法正常清理的情况,例如逻辑复制订阅端异常。在确认问题在于废弃的逻辑复制槽后,通过删除复制槽并进行checkpoint操作,成功清理wal日志,降低了空间占用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

问题描述

PG数据库实例磁盘空间使用率高达97%,其中wal空间使用量占用32G,相对比较异常。

在这里插入图片描述

处理思路

wal日志是PG数据库的事务预写日志,对于数据库的一个变更操作,数据库流程大概如下:
● 客户端执行DML操作进行数据变更
● 将相关的变更数据页写入wal buffer,对应的数据更新写到内存中的数据页(脏页)
● 事务commit时,wal buffer进行刷盘,写入到wal log,该步骤已经保证了数据不会丢失
● 周期性checkpoint出发将内存中的脏页进行刷盘

对于wal日志,PG数据库也提供了一些参数以及机制保证wal日志可周期性的进行归档,并控制相关大小,通过checkpoint来将历史无效的wal历史进行清理,从而避免wal日志占用过大的空间。所以针对wal日志两空间使用较大的情况,我们可以分两步去排查:
1)检查wal相关参数
● max_wal_size( integer) : 两次checkpoint之间允许的最大wal日志大小,这是一个软限制,当重负载、失败archive_command等情况下可能超出该参数设置大小。增加此参数会增加崩溃恢复所需的时
● min_wal_size( integer) :只要 WAL 磁盘使用率保持在此设置以下,旧的 WAL 文件总是会在检查点被回收以备将来使用,而不是被删除。这可用于确保保留足够的 WAL 空间来处理 WAL 使用量的峰值,例如在运行大型批处理作业时。
● wal_keep_segments : 主节点数据库为standby节点保留的最大wal log数量
● wal_level : wal日志记录模式
2)在参数设置正常的情况下,定位一些可能会导致wal日志无法正常清理的情况
● standby数据库实例复制存在一定的异常,导致主节点保存大量的wal日志
● 逻辑复制订阅端数据消费异常,导致发布节点堆积大量的wal日志

处理过程

1、检查wal相关参数
可以看到wal相关的参数设置基本都是正常的,wal_level设置为logical,一定程度上会增大wal日志空间使用量,但是也不至于会导致wal日志量使用高达32G


psql=#SELECT * FROM pg_settings where name like '%wal%'
+------------------------------+-------------------+----------------+-------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------+-------------------+-------------------+--------------------+-------------------+-------------------+-------------------------------------------+--------------------+---------------------+----------------------+----------------------+---------------------------+
| NAME                         | SETTING           | UNIT           | CATEGORY                      | SHORT_DESC                                                                                              | EXTRA_DESC                                                                                               | CONTEXT           | VARTYPE           | SOURCE             | MIN_VAL           | MAX_VAL           | ENUMVALS                                  | BOOT_VAL           | RESET_VAL           | SOURCEFILE           | SOURCELINE           | PENDING_RESTART           |
+------------------------------+-------------------+----------------+-------------------------------+---------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------+-------------------+-------------------+--------------------+-------------------+-------------------+-------------------------------------------+--------------------+---------------------+----------------------+----------------------+---------------------------+
| max_wal_senders              | 20                |                | Replication / Sending Servers | Sets the maximum number of simultaneously running WAL sender processes.                                 |                                                                                                          | postmaster        | integer           | configuration file | 0                 | 262143            |                          
### 使用 Prometheus 监控 PostgreSQL 数据库时的问题日志及解决方案 在使用 Prometheus 和其生态系统中的组件(如 Exporter)来监控 PostgreSQL 数据库的过程中,可能会遇到各种问题。以下是常见的问题及其对应的解决方法: #### 1. **Exporter 配置错误** 如果 PostgreSQL Exporter 的配置不正确,可能导致无法正常抓取指标数据。 - **常见原因**: `pg_hba.conf` 中未允许 Exporter 进行连接,或者数据库用户名和密码配置有误。 - **解决方案**: 确保 PostgreSQL 的访问权限已正确设置,在 `pg_hba.conf` 文件中添加如下条目[^2]: ``` host all exporter_user 0.0.0.0/0 md5 ``` 同时确认 Exporter 所需的用户已在 PostgreSQL 中创建并赋予适当权限。 #### 2. **WAL 日志相关问题** 当 WAL (Write-Ahead Logging) 设置不当,可能会影响性能或导致同步失败。 - **常见原因**: 参数 `wal_level`, `max_wal_senders` 或者 `archive_command` 配置不合理。 - **解决方案**: 调整这些参数以适应实际需求。例如: ```plaintext wal_level = replica max_wal_senders = 5 archive_mode = on archive_command = 'cp %p /path/to/archive/%f' ``` 上述配置可以确保流复制和其他高级功能能够正常使用[^1]。 #### 3. **Prometheus 抓取超时** Prometheus 可能在尝试从 Exporter 获取数据时发生超时。 - **常见原因**: PostgreSQL 实例响应速度过慢,可能是由于硬件资源不足或 SQL 查询效率低下引起。 - **解决方案**: 提高服务器资源配置,优化查询语句,并合理调整以下参数以提升性能[^4]: ```plaintext shared_buffers = 256MB work_mem = 64MB maintenance_work_mem = 128MB ``` #### 4. **Alertmanager 配置异常** 即使 Prometheus 成功收集到数据,但如果 Alertmanager 没有正确配置,则告警通知不会发送给相关人员。 - **常见原因**: YAML 文件语法错误或是网络连通性存在问题。 - **解决方案**: 检查 Promethues 和 Alertmanager 的配置文件是否有拼写或其他格式上的失误;另外测试两者之间的通信是否通畅。 ```yaml route: group_by: ['alertname'] receiver: 'email-notifications' receivers: - name: 'email-notifications' email_configs: - to: 'admin@example.com' ``` 以上代码片段展示了一个简单的路由规则以及接收器定义例子。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值