Postgresql清理WAL日志

L.ZZ

已于 2023-02-23 17:32:31 修改

阅读量8.1k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： PostgreSQL 文章标签： postgresql 数据库 oracle

于 2020-04-16 16:40:56 首次发布

原文链接：https://blog.youkuaiyun.com/dazuiba008/article/details/100659749

PostgreSQL 专栏收录该内容

6 篇文章

订阅专栏

本文详细介绍了PostgreSQL中WAL(Write Ahead Log)日志的工作原理，包括其存放位置、参数配置、自动清理条件及手动清理方法。阐述了在不同配置下WAL日志的保存数量限制，以及归档对日志清理的影响。

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

1. 前言

WAL是Write Ahead Log的简写，和oracle的redo日志类似，存放在$PGDATA/pg_xlog中，10版本以后在$PGDATA/pg_wal目录.
WAL相关的介绍可见WAL(Write Ahead Logging)介绍

如果开启了归档，在目录archive_status下会有一些文件，以ready结尾的，表示可以归档但还没有归档，done结尾的表示已经归档。

和WAL日志数量相关的几个参数：

wal_keep_segments = 300          # in logfile segments, 16MB each; 0 disables  
checkpoint_completion_target = 0.5     # checkpoint target duration, 0.0 - 1.0  
checkpoint_segments = 2048              # in logfile segments, min 1, 16MB each  
#9.5以后checkpoint_segments不再使用，要参考设置以下两个参数
#max_wal_size = 1GB  #最大不超过这个值
#min_wal_size = 80MB  #最小保留这个值

如果没有开启归档的情况下：
不超过以下两个公式计算得出的个数：

(2 + checkpoint_completion_target) * checkpoint_segments + 1
或者checkpoint_segments + wal_keep_segments + 1

9.5以后，如果超过了max_wal_size，那么就会删除不需要的wal.

如果开启了归档，那么归档成功了，才会被清除，所以这里注意一下，如果你开启了归档，但是归档命令是失效的，那么wal目录会一直增长，不会自动删除WAL，会使得此目录被撑爆。

2. 什么情况下回自动清理wal

做检查点的时候;
数据库启动的时候，或者修改了相关参数后重启数据库。

触发检查点的情况：
从前一个检查点发生过后的时间超过checkpoint_timeout设置的间隔（默认间隔为300秒（5分钟））。
在版本9.4或更早版本中，自上一个检查点以来，超过使用checkpoint_segments（默认数量为3）设置的WAL段文件数量。
在9.5或更高版本中，pg_xlog（版本10或更高版本，pg_wal）中WAL段文件的总大小已超过参数max_wal_size的值（默认值为1GB（64个文件））。
PostgreSQL服务在smart和fast模式下停止。
手动执行checkpoint.

3. 如何手动清理wal

可以通过缩小以上涉及到的函数减少wal segment的数量，也可以手动删除，如下：

pg_controldata

Latest checkpoint location: 16/79FF5520
Latest checkpoint’s REDO location: 16/79FF54E8
Latest checkpoint’s REDO WAL file: 00000001000000160000001E

这里表示16/79FF54E8检查点已经执行，已经包含在00000001000000160000001E日志文件中，那么这个日志之前的日志是可以清理的。

可以手动使用系统命令rm清理，也可以使用pg_archivecleanup清理
比如：

查看日志
ll
total 833M
-rw------- 1 postgres postgres  64M Aug 29 11:10 00000001000000160000001E
-rw------- 1 postgres postgres  64M Jul 16 11:24 00000001000000160000001F
-rw------- 1 postgres postgres  64M Jul 16 11:24 000000010000001600000020
-rw------- 1 postgres postgres  64M Jul 16 11:25 000000010000001600000021
-rw------- 1 postgres postgres  64M Jul 16 11:25 000000010000001600000022
-rw------- 1 postgres postgres  64M Jul 16 11:26 000000010000001600000023
-rw------- 1 postgres postgres  64M Jul 16 11:24 000000010000001600000024
-rw------- 1 postgres postgres  64M Jul 16 11:24 000000010000001600000025
-rw------- 1 postgres postgres  64M Jul 16 11:26 000000010000001600000026
-rw------- 1 postgres postgres  64M Jul 16 11:40 000000010000001600000027
-rw------- 1 postgres postgres  64M Jul 16 11:40 000000010000001600000028
-rw------- 1 postgres postgres  64M Jul 16 11:51 000000010000001600000029
-rw------- 1 postgres postgres  64M Jul 16 11:40 00000001000000160000002A
drwx------ 2 postgres postgres 4.0K Jun 18 10:15 archive_status

保留000000010000001600000027之后的日志
 pg_archivecleanup /opt/pgdata11.3/pg_root/pg_wal/  000000010000001600000027
 
 再次查看验证
 ls
000000010000001600000027  000000010000001600000028  000000010000001600000029  00000001000000160000002A  archive_status