作者崔鹏, 曾取得中国 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

文章起源：云贝学院