使用pgBackRest并行归档解决wal堆积问题

文章描述了在PostgreSQL数据库中,由于wal日志堆积导致磁盘告警的问题。作者分析了max_wal_size和wal_keep_segments参数对wal日志的影响,并发现归档速度慢于wal生成速度是主要原因。为解决此问题,文章引入了pgBackRest工具,利用其并行、异步WAL Push和Get特性,提高了wal日志的归档速度,成功解决了wal堆积问题。

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

作者:温智尹

问题现象:

最近生产上一台postgresql云主机磁盘告警,查看各文件目录大小,发现pg_wal目录竟然占用600G+,数据目录300G。

现有架构:

rds云主机 一主一从
磁盘大小1.2T
数据盘为ssd 归档与备份存储在ks3存储文件上

解决思路:

1.查找wal日志持续不释放原因

首先我们得了解那些参数影响wal日志产生的量与pg_wal目录文件的大小:max_wal_size (integer)
:在自动WAL检查点使得WAL增长到最大尺寸。这是软限制;特殊情况下WAL大小可以超过
max_wal_size,如重负载下,错误archive_command,或者 较大wal_keep_segments的设置。缺省是1GB。
增加这个参数会延长崩溃恢复所需要的时间。 这个参数只能在postgresql.conf文件或者服务器命令行上设置。
wal_keep_segments (integer)
:指定在后备服务器需要为流复制获取日志段文件的情况下,pg_wal目录下所能保留的过去日志文件段的最小数目。每个段通常是 16
兆字节。如果一个连接到发送服务器的后备服务器落后了超过wal_keep_segments个段,发送服务器可以移除一个后备机仍然需要的WAL
段,在这种情况下复制连接将被中断。最终结果是下行连接也将最终失败(不过,如果在使用 WAL 归档,后备服务器可以通过从归档获取段来恢复)。
只设置pg_wal中保留的文件段的最小数目;系统可能需要为 WAL
归档或从一个检查点恢复保留更多段。如果wal_keep_segments为零(默认值), 更多的空间来
存放WAL归档或从一个检查点恢复。如果wal_keep_segments是零(缺省),
系统不会为后备目的保留任何多余的段,因此后备服务器可用的旧 WAL 段的数量是一个上个检查点位置和 WAL
归档状态的函数。这个参数只能在postgresql.conf文件中或在服务器命令行上设置

如上解释,影响wal日志个数的原因主要有以上两个参数,查找该实例相关参数的值

postgres=# show max_wal_size; 
max_wal_size 
-------------- 
10GB 
postgres=# show wal_keep_segments ; 
wal_keep_segments 
------------------- 
600 

综合来看,在数据库正常情况下,pg_wal 目录文件大小应该在10G左右,那么为什么现在会产生600G+的wal,其实上述参数已经给了我们答案:特殊情况下WAL大小可以超过 max_wal_size,如重负载下,错误archive_command,或者 较大wal_keep_segments的设置。于是检查pg_wal/archive_status下文件,发现有大量xxx.ready的文件,表示该wal日志还未及时归档。结合现有架构,归档过程中由于ks3存储文件在性能限制上归档速度远远慢于本地ssd上wal日志产生的速度,所以wal无法及时归档,不断累积,最终造成磁盘告警。 原因找到了,接下来就是解决办法。

2.解决方法
加快wal归档速度

查看归档命令:

archive_command = 'DIR=/ks3data/wal/v3/d5ddd1d7-f458-4c50-ae23-012abc6e0570/723f790f-b66b-4312-bf08-02f8d0f083e5/`date +%F`; sudo test ! -d $DIR && sudo mkdir $DIR
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值