PG Wal 日志清理

1.wal日志介绍

WAL是Write Ahead Log的简写，和oracle的redo日志类似，存放在$PGDATA/pg_wal目录中,如果开启了归档，在目录archive_status下会有一些文件，以ready结尾的，表示可以归档但还没有归档，done结尾的表示已经归档。

2.wal 相关的参数

#wal_segment_size         --报告预写日志段的大小。默认值为 16MB
#wal_keep_segments        --指定保存在pg_wal目录中的过去日志文件段的最小数量，以防备用服务器需要获取它们以进行流复制。pg13改为wal_keep_segments 

#checkpoint_completion_target = 0.5   --指定检查点完成的目标，作为检查点之间总时间的一部分。默认值为 0.5 
#checkpoint_timeout=300                --自动 WAL 检查点之间的最长时间。如果指定此值没有单位，则以秒为单位。有效范围在 30 秒到 1 天之间。默认值为五分钟 ( 5min)。
#max_wal_size = 1GB    --最大不超过这个值 ,在自动检查点期间让 WAL 增长的最大大小。这是一个软限制；WAL 大小max_wal_size在特殊情况下可能会超出，例如重负载、失败archive_command或高wal_keep_segments设置。如果此值指定为不带单位，则以兆字节为单位。默认值为 1 GB。
#min_wal_size = 80MB   --最小保留这个值,只要 WAL 磁盘使用率低于此设置，旧的 WAL 文件总是在检查点被回收以供将来使用，而不是被删除。这可用于确保保留足够的 WAL 空间来处理 WAL 使用中的峰值，例如在运行大型批处理作业时。如果此值指定为不带单位，则以兆字节为单位。默认值为 80 MB。

3.清理方式

3.1.wal 自动清理

＃软件限制，当日志达到这个最大值时，会做一个检查点。 
postgres=# show max_wal_size;
 max_wal_size
--------------
 8GB
(1 row)

＃ 保存多个日志　　
在PG13以前，我们能过wal_keep_segments  设置保存日志大小，在PG13后参数改为wal_keep_size
postgres=# show wal_keep_segments   
postgres-# ;
 wal_keep_segments
-------------------
 128
(1 row)
＃每个日志大小　
postgres=# show wal_segment_size ;
 wal_segment_size
------------------
 16MB
(1 row)

[postgres@LXUATEDPD2 wal]$ ls -lrt 000* | wc -l
512
512*16MB(wal_segment_size) = 8192MB = 8G (max_wal_size)

** 注意 **

1. 当 max_wal_size／wal_segment_size 与　 wal_keep_segments 这两个谁大保存谁
2. 只有当在做检查点时才会去清理日志
3. wal 日志里的 archive_status 里的状态比 pg_controldata $PGDATA 新， pg_controldata 只是在做检查 点时才会去更新。

3.2.wal手动清理

[postgres@LXUATEDPD2 log]$ pg_controldata $PGDATA
pg_control version number:            1201
Catalog version number:               201909212
Database system identifier:           7080150410741737694
Database cluster state:               in production
pg_control last modified:             Fri 08 Apr 2022 09:22:12 AM HKT
Latest checkpoint location:           17/3F000028
Latest checkpoint's REDO location:    17/3F000028
Latest checkpoint's REDO WAL file:    00000001000000170000003F
Latest checkpoint's TimeLineID:       1
Latest checkpoint's PrevTimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0:2180
Latest checkpoint's NextOID:          32768
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        480
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  2176
Latest checkpoint's oldestMultiXid:   1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint:            Fri 08 Apr 2022 09:22:05 AM HKT
Fake LSN counter for unlogged rels:   0/3E8
Minimum recovery ending location:     0/0
Min recovery ending loc's timeline:   0
Backup start location:                0/0
Backup end location:                  0/0
End-of-backup record required:        no
wal_level setting:                    replica
wal_log_hints setting:                on
max_connections setting:              2000
max_worker_processes setting:         128
max_wal_senders setting:              10
max_prepared_xacts setting:           0
max_locks_per_xact setting:           64
track_commit_timestamp setting:       off
Maximum data alignment:               8
Database block size:                  16384
Blocks per segment of large relation: 65536
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        4044
Size of a large-object chunk:         4096
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
Data page checksum version:           1
Mock authentication nonce:            4e7ad0bd2ddb2077bf0b5dceabbac911be4ef1e72634f197b5e433f4e70773ea
 #  清理指定 wal 日志以前的日志
[postgres@LXUATEDPD2 wal]$ pg_archivecleanup  -d /db_log/wal 00000001000000170000003F
pg_archivecleanup: keeping WAL file "/db_log/wal/00000001000000170000003F" and later

4.触发检查点的情况

1.从前一个检查点发生过后的时间超过checkpoint_timeout设置的间隔（默认间隔为300秒（5分钟））。
2.在新版本(9.5以后)当max_wal_size 大于pg_wal总和时，会触发检查点
3.PostgreSQL服务在smart和fast模式下停止。
4.手动执行checkpoint
5.数据库recover完成

来自为知笔记(Wiz)