织梦购物网站整站源码b站免费版入口

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 操作，会往 WAL 日志里写 checkpoint 位点。

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也做相应增加。生产系统可以根据实际业务需求适当调整该参数。