[转帖]PostgreSQL WAL日志清理

postgresql,wal,日志,清理 · 浏览次数 : 0

小编点评

**WAL相关参数** * **wal_compression**: 设置wal压缩，默认值为`off`。 * **wal_log_hints**: 设置wal日志的提示，默认值为`off`。 * **wal_buffers**: 设置wal缓存大小，默认值为-1，表示使用操作系统缓存。 * **wal_writer_delay**: 设置wal写入延迟时间，默认值为200毫秒。 * **commit_delay**: 设置提交事务后等待wal日志写入磁盘的时间，默认值为0。 * **commit_siblings**: 设置多个事务提交后，必须等待至少该数个事务完成才能写入wal日志。 * **wal_buffer_size**: 设置wal缓存大小，默认值为16MB。 * **check_points**: 设置检查点的间隔时间，默认值为1分钟。 * **autovacuum**: 设置自动 vacuum 的周期，默认值为每天。 * **archive_control**: 设置wal存档控制选项，默认值为`off`。

正文

https://www.modb.pro/db/65309

pg_archivecleanup -d $PGDATA/pg_wal `pg_controldata $PGDATA |grep "REDO WAL" |awk '{print $6}'`

作者：崔鹏,曾获得中国PostgreSQL数据库管理高级工程师(PGCM),是PostgreSQL官方认证讲师,Mysql 5.7/8.0 OCP,Oracle 11g OCM。

WAL是Write Ahead Log的简写,10版本以后在$PGDATA/pg_wal目录中 10之前的版本在$PGDATA/pg_xlog.

# wal相关参数

#wal_compression = off

如果当全页写成为io瓶颈时，可以设置为on

#wal_log_hints = off

如果使用pg_rewind，需要设置为on

#wal_buffers = -1

默认-1会根据shared_buffers自动调整

打开这个选项的时候，PostgreSQL服务器在检查点之后对页面的第一次写入时将整个页面写到 WAL 里面。这么做是因为在操作系统崩溃过程中可能只有部分页面写入磁盘，从而导致在同一个页面中包含新旧数据的混合。在崩溃后的恢复期间，由于在WAL里面存储的行变化信息不够完整，因此无法完全恢复该页。把完整的页面影像保存下来就可以保证正确存储页面，代价是增加了写入WAL的数据量。因为WAL重放总是从一个检查点开始的，所以在检查点后每个页面第一次改变的时候做WAL备份就足够了。因此，一个减小全页面写开销的方法是增加检查点的间隔参数值。

#wal_writer_delay = 200ms

wal writer进程的间歇时间，过大的话，可能会造成wal buffer不足，过小的话wal会不断写入，可能会有io瓶颈

#commit_delay = 0

至少有commit_siblings个并发事务时，该事务提交后，wal日志将延迟commit_delay时间后再写入磁盘。可以合并其他事务进行组提交，所以当有大量事务的时候会延迟，而如果事务很稀少就不会再被延迟了。非0值的影响：减少IO，提高性能：事务执行commit后不会立即写入磁盘，而存放在WAL buffer中，崩溃数据面临着丢失的危险，可能引起WAL buffer内存不足，尤其是提交事务较多的高峰期

#commit_siblings = 5

延迟提交wal日志的最小并发事务数，决定参数commit_delay是否生效。假设值是5，表示数据库中正在执行的事务数大于或等于5，该事务提交后，wal日志将会存入wal buffer中，延迟commit_delay时间后再写入磁盘。如果数据库中正在执行的事务数小于5，这个事务提交后将wal日志直接写入磁盘。

自动清理wal条件

1.做检查点的时候

2.数据库启动的时候，或者修改了相关参数后重启数据库。

手动清理WAL

postgres@pgexp1-> pg_controldata
pg_control version number:            1201
Catalog version number:               201909212
Database system identifier:           6931137589662892022
Database cluster state:               in production
pg_control last modified:             Wed 03 Mar 2021 07:54:25 AM CST
Latest checkpoint location:           0/163CBD0
Latest checkpoint's REDO location:    0/163CB98
Latest checkpoint's REDO WAL file:    000000010000000000000003 #当前的时间线位置
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on

这里表示0/163CBD0检查点已经执行，已经包含在000000010000000000000003日志文件中，这个日志之前的日志是可以清理的。

可以手动使用系统命令rm -f清理

也可以使用pg_archivecleanup清理

保留000000010000000000000002之后的日志

pg_archivecleanup opt/pg_root/pg_wal/  000000010000000000000002