一、PostgreSQL常见配置参数
max_wal_size :
两个检查点（checkpoint）之间，WAL可增长的最大大小，即：自动WAL checkpoint允许WAL增长的最大值。
该值缺省是1GB。如果提高该参数值会提升性能，但也是会消耗更多空间、同时会延长崩溃恢复所需要的时间。
注意：这个参数是个软限制，不是硬限制，因此实际WAL可能会超过这个值（如：较大的 wal_keep_segments 设置）。
min_wal_size :
检查点（checkpoint）后用来保留的，用于未来循环使用的WAL文件。可以被用来确保有足够的WAL空间被保留来应付WAL使用的高峰，以供将来的检查点使用。这可以用来确保预留足够的WAL空间处理WAL使用中的峰值，比如当运行大批量工作时。
如果PG空闲时，会逐渐将WAL量减少到 min_wal_size。
该值缺省是80MB。请不要将该值设置的太小。
查看数据库 min_wal_size & max_wal_size 参数配置：
testdb01=> select name, setting, unit, short_desc from pg_settings where name like '%wal_size%';
max_wal_size | 1024 | MB | Sets the WAL size that triggers a checkpoint.
min_wal_size | 80 | MB | Sets the minimum size to shrink the WAL to.
也可以执行:
testdb01=> show max_wal_size;
1GB
testdb01=> show min_wal_size;
80MB
testdb01=>
WAL空间使用情况：
如果日志量大于 max_wal_size，则WAL日志空间尽量保持在 max_wal_size 。因为会触发检查点，不需要的段文件将被移除直到系统回到这个限制以下。
如果日志量小于 max_wal_size，则WAL日志空间至少保持 min_wal_size。可以被用来确保有足够的WAL空间被保留来应付WAL使用的高峰，以供将来的检查点使用。
通常情况下，WAL日志空间大小在 min_wal_size ~ max_wal_size 之间动态评估。该估计基于在以前的检查点周期中使用的WAL文件数的动态平均值。如果实际使用量超过估计值，动态平均数会立即增加。
-bash-4.2$ cd $PGDATA
-bash-4.2$ du -sh pg_wal && ls -lh pg_wal/
1.2G pg_wal
total 1.2G
-rw-------. 1 postgres postgres 16M Feb 6 09:20 000000010000000000000001
-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000002
-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000003
-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000004
-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000005
......
-rw-------. 1 postgres postgres 16M Feb 14 19:11 00000001000000000000003E
-rw-------. 1 postgres postgres 16M Feb 14 19:11 00000001000000000000003F
-rw-------. 1 postgres postgres 16M Feb 14 19:11 000000010000000000000040
-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000041
-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000042
-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000043
-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000044
-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000045
-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000046
-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000047
drwx------. 2 postgres postgres 6 Dec 6 2021 archive_status
-bash-4.2$
pg_wal大小至少保留 80MB 的文件，也就是 000000010000000000000001~47 所有文件至少保留 80MB
执行checkpoint以后，pg_wal大小可能会降低到 max_wal_size 以内，多次执行checkpoint不一定会降低到 min_wal_size，这还处决于很多其他配置和因素。
关于checkpoint
checkpoint：
A checkpoint is a point in the write-ahead log sequence at which all data files have been updated to reflect the information in the log. All data files will be flushed to disk.
checkpoint是WAL(write-ahead log)日志中的一个位点，在这个点位之前数据库中的所有数据都和WAL日志中反映的信息相同，也就是说该位点之前所有 Shared Buffer 中的脏页均已被刷入到存储磁盘。
checkpoint 是一个名词，同时也是一个动词，执行一个 checkpoint SQL操作，会往 WAL 日志里写 checkpoint 位点。checkpoint SQL命令的官方介绍参考：http://postgres.cn/docs/10/sql-checkpoint.html
数据库何时进行checkpoint操作：
1）超级用户手动执行checkpoint命令
2）checkpoint_timeout 配置参数中指定的间隔到达（默认300秒）
3）写入WAL的数据量（du -sh $PGDATA/pg_wal）已达到参数 max_wal_size（默认值：1GB），软限制、实际可能会超出
4）online backup 开始的时候
5）pg_start_backup 执行时
6）数据库实例关闭时
7）CREATE/DROP DATABASE等数据库配置操作时
执行checkpoint时，数据库主要完成以下几个工作：
a）识别Shared Buffers中所有的脏页；
b）将脏页写入相应的数据文件；
c）确保修改后的文件通过fsync()写入到磁盘。
PostgreSQL 写数据的过程：
INSERT INTO test01 VALUES(1);
流程如下：
step1：将 INSERT 1 这个操作写入 WAL 日志中。 WAL 日志是物理日志，记录的是对某个文件某个块的修改。
step2：修改 Shared Buffer 中该页的信息（如果该页不在 Buffer 中，则从磁盘去取），test01表中写入1。此时如果有表的读取则直接读取Shared Buffer返回数据。
step3：background writer 写磁盘(disk)。background 进程会在某个时刻将 Shared Buffer 中的数据刷到磁盘。但是这并不是立刻发生的，而是一个异步操作。
PostgreSQL数据库故障恢复：
如果上面step3过程中出现故障、background wirter 写磁盘失败了，那么PostgreSQL重启会进入恢复模式，会基于上次 checkpoint点位和 WAL(Redo) 日志进行重放，从而将数据刷到磁盘。
checkpoint 操作会往 WAL 日志里写 checkpoint 位点。例如：
WAL: | ... | INSERT 1 | INSERT 2 | ... | INSERT 3 | checkpoint |
|
-> 这里（INSERT 1之后）执行一个checkpoint操作，产生一个 redo point（重做位点），从这里开始到checkpoint写入时一个完整的checkpoint过程
checkpoint整个流程过程如下：
step1：checkpoint 操作首先记录下 checkpoint 的开始位置（INSERT 2之后），记录为 redo point（重做位点）;
step2：checkpoint 将 Shared Buffer 中的数据刷到磁盘里面去；
step3：这时候数据库又来了一条 SQL：INSERT 3；
step4：checkpoint 刷脏结束，redo point 之前的数据均已被刷到磁盘存储（数据1和2）；
step5：这时候在 WAL 日志里面记录 checkpoint 位点（INSERT 3后），表明 checkpoint 操作结束。checkpoint 位点会记录相关信息，比如 redo point 的值（从哪开始重做）；
step6：将最新的 checkpoint 位点记录在 pg_control 文件中。
从上面的流程可以看出，checkpoint 操作已经能保证将 redo point 位点之前的数据落盘了，那 redo point 之前的所有 WAL 日志都已经没有用了（即使下次故障，这部分数据已经被持久化落盘了，也不需要恢复），就可以请理了。不过有些特殊情况，即使WAL日志已经没有用了，也可能导致不被自动清理，例如创建了流复制插槽但未使用/消费。
数据库数据目录下pg_wal的WAL文件在开启归档的模式下，会将已归档WAL文件自动清理。
如果开启了归档，在pg_wal/archive_status目录下会有一些文件，以ready结尾的，表示可以归档但还没有归档，以done结尾的表示已经归档。
WAL文件的自动清理流程如下：
转储WAL段文件到disk，写满或者使用 pg_switch_wal() 后，会生成000000xxxx.ready文件，调用archive_command 命令且成功执行后，将ready文件更名为.done文件。而数据库会在执行checkpoint后计算出最旧的需保留的WAL文件，比该值更早的WAL文件均会被清理。
shared_buffers：
shared_buffers 是缓存。在数据库系统中，我们主要关注磁盘IO，而且其大多是随机IO，因此从磁盘的读取比较慢，为了解决这个问题，postgresql将数据缓存在内存中，牺牲内存来换取随机读取的性能。
shared_buffers 参数用来设置数据库服务器将使用的共享内存缓冲区量。默认通常是 12MB，但是如果你的内核设置不支持（在initdb时决定），那么可以会更少，但不能小于 128kB。
不过为了更好的性能，通常会使用明显高于最小值的设置。 如果指定值时没有单位(MB等)，则以块为单位，即BLCKSZ字节，通常为8kB。此参数只能在服务器启动时设置。
如果服务器内存被数据库专用、服务器内存 >= 1GB，合理的shared_buffers初始值是设置为系统内存的25%。shared_buffers并非越大越好，shared_buffers增大，也会造成一些工作负载。超过内存 40% 反而会不好。
shared_buffers更大的设置通常要求对max_wal_size也做相应增加。生产系统可以根据实际业务需求适当调整该参数。
二、PostgreSQL常用命令
WAL日志及LSN查询：
1.查看视图 pg_replication_slots 信息：
testdb01=> select * from pg_replication_slots ;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
--------------------+---------------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
replication_slot01 | test_decoding | logical | 16437 | testdb01 | f | f | | | 590 | 0/180A540 | 0/180A578
replication_slot02 | pgoutput | logical | 16437 | testdb01 | f | f | | | 594 | 0/180C270 | 0/29AA7B0
(2 rows)
2.pg_controldata 查看控制信息：
$ pg_controldata
pg_control version number: 1201
Catalog version number: 201909212
Database system identifier: 7038444130751219893
Database cluster state: in production
pg_control last modified: Fri 10 Feb 2023 02:29:59 PM CST
Latest checkpoint location: 0/29AA700
Latest checkpoint's REDO location: 0/29AA6C8
Latest checkpoint's REDO WAL file: 000000010000000000000002
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0:626
Latest checkpoint's NextOID: 35373
......
3.查询数据库LSN等信息：
-- PG10以前的版本
select pg_current_xlog_location(),pg_xlogfile_name(pg_current_xlog_location()),pg_xlogfile_name_offset(pg_current_xlog_location());
其中：
pg_current_xlog_location()：获得当前wal日志写入位置。
pg_xlogfile_name():转换wal日志位置为文件名。
pg_xlogfile_name_offset():返回转换后的wal日志文件名和偏移量。
-- PG10及以后版本
select pg_current_wal_lsn(),pg_walfile_name(pg_current_wal_lsn()),pg_walfile_name_offset(pg_current_wal_lsn());
testdb01=> select pg_current_wal_lsn(),pg_walfile_name(pg_current_wal_lsn()),pg_walfile_name_offset(pg_current_wal_lsn());
pg_current_wal_lsn | pg_walfile_name | pg_walfile_name_offset
--------------------+--------------------------+-------------------------------------
0/29AA7B0 | 000000010000000000000002 | (000000010000000000000002,10135472)
(1 row)
其中：
pg_current_wal_lsn()： 获得当前wal日志写入位置。
pg_walfile_name()： 转换wal日志位置为文件名。
pg_walfile_name_offset()：返回转换后的wal日志文件名和偏移量。
说明
LSN:0/29AA7B0
0：代表wal文件的第二部分
2：代表wal文件的最后两位02
9AA7B0：代表对应日志文件内的偏移量
4.查看pg_wal目录下的日志文件：
$ ls -l $PGDATA/pg_wal
total 32768
-rw-------. 1 postgres postgres 16777216 Feb 6 09:20 000000010000000000000001
-rw-------. 1 postgres postgres 16777216 Feb 10 14:30 000000010000000000000002
drwx------. 2 postgres postgres 6 Dec 6 2021 archive_status
wal文件由三部分组成每个4字节（8个16进制字符）总共12字节24个16进制字符。第一部分（4字节）代表时间线（TimeLineID）、第二部分代表LSN高32位、第三部分代表LSN低32位（LSN低32位的最高两位代表该日志文件的LSN起始编号）。
000000010000000000000002 日志文件名的格式如下：
00000001：第一部分（4字节）代表数据库运行的时间轴，如果恢复过数据库（主备切换）这个值会增大；
00000000：第二部分、LSN高32位；
00000002：第三部分、LSN低32位。其中最高两位为0代表LSN该日志文件的LSN其实编号为0。
根据时间线 00000001 和 0/29AA7B0 可以推算出日志文件为：000000010000000000000002，对位的文件内的偏移为：0x9AA7B0 = 10135472
5.查询当前的最新LSN和WAL文件：
testdb01=> select * from pg_control_checkpoint();
checkpoint_lsn | redo_lsn | redo_wal_file | timeline_id | prev_timeline_id | full_page_writes | next_xid | next_oid | next_multixact_id | next_multi_offset |
oldest_xid | oldest_xid_dbid | oldest_active_xid | oldest_multi_xid | oldest_multi_dbid | oldest_commit_ts_xid | newest_commit_ts_xid | checkpoint_time
----------------+-----------+--------------------------+-------------+------------------+------------------+----------+----------+-------------------+-------------------+-
-----------+-----------------+-------------------+------------------+-------------------+----------------------+----------------------+------------------------
0/29AA700 | 0/29AA6C8 | 000000010000000000000002 | 1 | 1 | t | 0:626 | 35373 | 1 | 0 |
479 | 1 | 626 | 1 | 1 | 0 | 0 | 2023-02-10 14:29:56+08
(1 row)
testdb01=>
WAL(Write Ahead Log)预写日志
WAL(Write Ahead Log)预写式日志，类似于Oracle的Redo日志。区别是Oracle中Redo是配置固定几个Redo日志文件，然后轮着切换去写入。而PostgreSQL中WAL日志是动态切换的，单个WAL日志文件写满后继续写下一个WAL日志文件，连续不断生成很多WAL日志文件。
单个WAL日志文件的大小默认16MB。适当提高单个WAL日志文件的大小会降低磁盘IO操作、性能有一定提升。
PG11.0以下的版本不支持动态调整、而是在编译postgresql时通过参数"--with-wal-segsize"设置，编译后不能修改。
PG11.0及以后的版本支持通过参数"wal_segment_size"动态调整、数据库启动初始化时生效。另外也可以通过initdb配置选项"--with-wal-segsize"来修改配置。
WAL的核心概念是，对数据文件(表和索引所在的地方)的更改必须在写入了日志文件后这些更改之后才可以写入数据文件，也就是说，描述更改的日志记录被刷新到永久存储之后才可以写数据文件。
使用WAL可以显著减少磁盘写操作的数量，因为只需要将日志文件刷新到磁盘以确保提交事务，而不是事务更改的每个数据文件。日志文件是按顺序写入的，因此同步日志的成本要比刷新数据页的成本低得多。
备注：
1）数据库将脏数据刷到数据文件上，这个动作是随机I/O，性能远比写日志文件的顺序I/O差太多。
2）数据库事务：数据库事务在实现的时候，要保证数据落盘成功才能返回。落盘是指落盘到自己的事务日志文件里就返回成功，而不是直接写入到数据库表文件里。原因还是磁盘读写性能问题，事务只要落盘成功就可以，写到哪里不重要。写到一个日志文件中，就是顺序IO，而写到数据文件就变成随机IO了。
3）更多 WAL内部详情（包括故障恢复过程），可参考官方文档说明：http://postgres.cn/docs/10/wal-internals.html
WAL日志归档
1.手动触发WAL日志归档：
select pg_switch_xlog(); -- pg10.0之前的版本
select pg_switch_wal(); -- pg10.0之后的版本
执行手动日志归档以后，WAL会切换到新的日志文件，这时会将老的WAL日志归档。
2.自动WAL日志归档：
1）WAL日志写满后触发自动归档
WAL每个日志文件大小的默认配置是16MB，WAL日志文件写满后切换WAL日志文件，会触发自动归档。
PG11.0以下的版本不支持动态调整、而是在编译postgresql时通过参数"--with-wal-segsize"设置，编译后不能修改。
PG11.0及以后的版本支持通过参数"wal_segment_size"动态调整、数据库启动初始化时生效。另外也可以通过initdb配置选项"--with-wal-segsize"来修改配置。
2）archive_timeout 时间控制自动归档：
在 postgresql.conf 配置文件中的 archive_timeout 参数控制，如果设置 archive_timeout = 180s，则WAL日志会每 180s 切换一次WAL日志、并同时触发日志归档。
archive_timeout 的默认值是0、即未开启。
注意：不推荐设置 archive_timeout ，如果要设置，那也尽量不要把 archive_timeout 参数设置过小，如果太小会导致你配置的归档存储空间开销膨胀。因为，达到归档时间强制归档的日志，即使WAL日志文件没有写满，也会是默认的16MB（假设 wal_segment_size = 16MB 默认值）。
