WAL相关参数:
postgres=# select name,setting from pg_settings where name like 'wal%';
name | setting
------------------------------+-----------
wal_block_size | 8192
wal_buffers | 12800
wal_compression | on
wal_consistency_checking |
wal_init_zero | on
wal_keep_segments | 3000
wal_level | replica
wal_log_hints | off
wal_receiver_status_interval | 10
wal_receiver_timeout | 60000
wal_recycle | on
wal_retrieve_retry_interval | 5000
wal_segment_size | 16777216
wal_sender_timeout | 60000
wal_sync_method | fdatasync
wal_writer_delay | 10
wal_writer_flush_after | 0当这个参数为打开时,PostgreSQL服务器在一个检查点之后的页面的第一次修改期间将每个页面的全部内容写到 WAL 中。这么做是因为在操作系统崩溃期间正在处理的一次页写入可能只有部分完成,从而导致在一个磁盘页面中混合有新旧数据。在崩溃后的恢复期间,通常存储在 WAL 中的行级改变数据不足以完全恢复这样一个页面。存储完整的页面映像可以保证页面被正确存储,但代价是增加了必须被写入 WAL 的数据量(因为 WAL 重放总是从一个检查点开始,所以在检查点后每个页面的第一次改变时这样做就够了。因此,一种减小全页面写开销的方法是增加检查点间隔参数值)。
把这个参数关闭会加快正常操作,但是在系统失败后可能导致不可恢复的数据损坏,或者静默的数据损坏。其风险类似于关闭fsync, 但是风险较小。并且只有在可关闭fsync的情况下才应该关闭它。
关闭这个选项并不影响用于时间点恢复(PITR)的 WAL 归档使用。
这个参数只能在postgresql.conf文件中或在服务器命令行上设置。默认值是on。
wal_level:
wal_level决定多少信息写入到 WAL 中。默认值是replica,它会写入足够的数据以支持WAL归档和复制,包括在后备服务器上运行只读查询。minimal会去掉除从崩溃或者立即关机中进行恢复所需的信息之外的所有记录。最后,logical会增加支持逻辑解码所需的信息。每个层次包括所有更低层次记录的信息。这个参数只能在服务器启动时设置。
在minimal级别中,某些批量操作的 WAL 日志可以被安全地跳过,这可以使那些操作更快。这种优化可以应用的操作包括:
CREATE TABLE AS |
CREATE INDEX |
CLUSTER |
COPY到在同一个事务中被创建或截断的表中 |
但最少的 WAL 不会包括足够的信息来从基础备份和 WAL 日志中重建数据,因此,要启用 WAL 归档(archive_mode)和流复制,必须使用replica或更高级别。
在logical层,与replica相同的信息会被记录,外加上 允许从 WAL 抽取逻辑修改集所需的信息。使用级别 logical将增加 WAL 容量,特别是如果为了REPLICA IDENTITY FULL配置了很多表并且执行了很多UPDATE和DELETE 语句时。
在 9.6 之前的版本中,这个参数也允许值archive和hot_standby。现在仍然接受这些值,但是它们会被映射到replica。
如果打开这个参数,PostgreSQL服务器将尝试确保更新被物理地写入到磁盘,做法是发出fsync()系统调用或者使用多种等价的方法(见wal_sync_method)。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。
虽然关闭fsync常常可以得到性能上的收益,但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此,只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync
用来向强制 WAL 更新到磁盘的方法。如果fsync是关闭的,那么这个设置就不相关,因为 WAL 文件更新将根本不会被强制。可能的值是:
open_datasync(用open()选项O_DSYNC写 WAL 文件)fdatasync(在每次提交时调用fdatasync())fsync(在每次提交时调用fsync())fsync_writethrough(在每次提交时调用fsync(),强制任何磁盘写高速缓存的直通写)open_sync(用open()选项O_SYNC写 WAL 文件)
指定在命令返回“success”指示给客户端之前,一个事务是否需要等待 WAL 记录被写入磁盘。合法的值是on、remote_apply、remote_write、local和off。默认的并且安全的设置是on。当设置为off时,在向客户端报告成功和真正保证事务不会被服务器崩溃威胁之间会有延迟(最大的延迟是wal_writer_delay的三倍)。不同于fsync,将这个参数设置为off不会产生数据库不一致性的风险:一个操作系统或数据库崩溃可能会造成一些最近据说已提交的事务丢失,但数据库状态是一致的,就像这些事务已经被干净地中止。因此,当性能比完全确保事务的持久性更重要时,关闭synchronous_commit可以作为一个有效的代替手段
wal_sync_method (enum)
用来向强制 WAL 更新到磁盘的方法。如果fsync是关闭的,那么这个设置就不相关,因为 WAL 文件更新将根本不会被强制。可能的值是:
open_datasync(用open()选项O_DSYNC写 WAL 文件)fdatasync(在每次提交时调用fdatasync())fsync(在每次提交时调用fsync())fsync_writethrough(在每次提交时调用fsync(),强制任何磁盘写高速缓存的直通写)open_sync(用open()选项O_SYNC写 WAL 文件)
open_* 选项也可以使用O_DIRECT(如果可用)。不是在所有平台上都能使用所有这些选择。默认值是列表中第一个被平台支持的那个, 不过fdatasync是 Linux 中的默认值。默认值不一定是最理想的;有可能需要修改这个设置或系统配置的其他方面来创建一个崩溃-安全的配置,或达到最佳性能。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
full_page_writes (boolean)
当这个参数为打开时,PostgreSQL服务器在一个检查点之后的页面的第一次修改期间将每个页面的全部内容写到 WAL 中。这么做是因为在操作系统崩溃期间正在处理的一次页写入可能只有部分完成,从而导致在一个磁盘页面中混合有新旧数据。在崩溃后的恢复期间,通常存储在 WAL 中的行级改变数据不足以完全恢复这样一个页面。存储完整的页面映像可以保证页面被正确存储,但代价是增加了必须被写入 WAL 的数据量(因为 WAL 重放总是从一个检查点开始,所以在检查点后每个页面的第一次改变时这样做就够了。因此,一种减小全页面写开销的方法是增加检查点间隔参数值)。
指定 WAL 写入器刷写 WAL 的频繁程度,以时间为单位。 在刷写WAL之后,写入器将根据wal_writer_delay所给出的时间长度进行睡眠,除非被一个异步提交的事务提前唤醒。 如果最近的刷写发生在 wal_writer_delay 之前,并且小于 wal_writer_flush_after WAL的值产生之后,那么WAL只会被写入操作系统,而不会被刷写到磁盘。 如果指定值时没有单位,则以毫秒作为单位。 默认值是 200 毫秒(200ms)。注意在很多系统上,有效的睡眠延迟粒度是 10 毫秒,把wal_writer_delay设置为一个不是 10 的倍数的值,其效果和把它设置为大于该值的下一个 10 的倍数产生的效果相同。这个参数只能在postgresql.conf文件中或者服务器命令行上设置。
wal_writer_flush_after (integer)
指定 WAL 写入器刷写 WAL 的频繁程度,以卷为单位。 如果最近的刷写发生在 wal_writer_delay 之前,并且小于 wal_writer_flush_after WAL的值产生之后,那么WAL只会被写入操作系统,而不会被刷写到磁盘。 如果wal_writer_flush_after被设置为0,则WAL数据总是会被立即刷写。 如果指定值时没有单位,则以WAL块作为单位,即为XLOG_BLCKSZ字节,通常为8kB。 默认是1MB。这个参数只能在postgresql.conf文件中或者服务器命令行上设置。
在一次 WAL 刷写被发起之前,commit_delay增加一个时间延迟。 如果系统负载足够高,使得在一个给定间隔内有额外的事务准备好提交,那么通过允许更多事务通过一个单次 WAL 刷写来提交能够提高组提交的吞吐量。 但是,它也把每次 WAL 刷写的潜伏期增加到了最多commit_delay。 因为如果没有其他事务准备好提交,就会浪费一次延迟,只有在当一次刷写将要被发起时有至少commit_siblings个其他活动事务时,才会执行一次延迟。 另外,如果fsync被禁用,则将不会执行任何延迟。 如果指定值时没有单位,则以微秒作为单位。 默认的commit_delay是零(无延迟)。只有超级用户才能修改这个设置。
在PostgreSQL的 9.3 发布之前,commit_delay的行为不同并且效果更差:它只影响提交,而不是所有 WAL 刷写,并且即使在 WAL 刷写马上就要完成时也会等待一整个配置的延迟。从PostgreSQL 9.3 中开始,第一个准备好刷写的进程会等待配置的间隔,而后续的进程只等到领先者完成刷写操作。
在执行commit_delay延迟时,要求的并发活动事务的最小数目。大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务。
参考:http://www.postgres.cn/docs/12/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS