19.5. 预写式日志 #
参阅第 30.4 节获取调节这些设置的额外信息。
19.5.1. 设置 #
wal_level(enum) #wal_level决定多少信息写入到 WAL 中。默认值是replica，它会写入足够的数据以支持 WAL 归档和复制，包括在备库上运行只读查询。minimal会去掉除从崩溃或者立即关机中进行恢复所需的信息之外的所有记录。最后，logical会增加支持逻辑解码所需的信息。每个层次包括所有更低层次记录的信息。这个参数只能在服务器启动时设置。在
minimal级别，可以安全地跳过一些批量操作的 WAL 日志记录，使这些操作快得多（参见第 14.4.7 节）。可以应用此优化的操作包括：CREATE TABLE ASCREATE INDEXCLUSTER向同一事务中创建或截断的表执行 COPY但 minimal 级别的 WAL 不包含足够的信息来从基础备份和 WAL 日志重建数据，因此必须使用
replica或更高级别来启用 WAL 归档（archive_mode）和流复制。在
logical级别上，记录与replica相同的信息，以及从 WAL 中提取逻辑变更集所需的信息。使用logical级别会增加 WAL 的数量，特别是如果许多表被配置为REPLICA IDENTITY FULL，并且执行了许多UPDATE和DELETE语句。在 9.6 之前的版本中，这个参数也允许值
archive和hot_standby。现在仍然接受这些值，但是它们会被映射到replica。fsync(boolean) #如果打开这个参数，PostgreSQL 服务器将尝试确保更新被物理地写入到磁盘，做法是发出
fsync()系统调用或者使用多种等价的方法（见 wal_sync_method）。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态。虽然关闭
fsync常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏。因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync。可以安全关闭
fsync的情形包括：从备份文件初始装载一个新数据库集簇；用数据库集簇处理一批数据，处理后就丢弃并重建该数据库；或者使用经常重建且不用于故障切换的只读数据库克隆。仅有高质量硬件不足以成为关闭fsync的理由。为确保将
fsync从关闭改为打开后能够可靠恢复，必须将内核中所有已修改的缓冲区强制写入持久存储。可以在集簇已关闭或fsync已开启时，通过运行initdb --sync-only、运行sync、卸载文件系统或重启服务器来完成。在很多情况下，为非关键事务关闭 synchronous_commit，可以获得关闭
fsync所带来的大部分潜在性能收益，同时避免伴随的数据损坏风险。fsync只能在postgresql.conf文件中或在服务器命令行上设置。如果你关闭这个参数，请也考虑关闭 full_page_writes。synchronous_commit(enum) #指定数据库服务器向客户端返回“成功”指示之前，必须完成多少 WAL 处理。有效值为
remote_apply、on（默认值）、remote_write、local和off。如果
synchronous_standby_names为空，只有on和off两种设置有意义；remote_apply、remote_write和local提供的本地同步级别都与on相同。所有非off模式在本地都会等待 WAL 刷写到磁盘。在off模式下则无需等待，因此，向客户端报告成功后，可能还要经过一段时间，才能保证事务不会因服务器崩溃而丢失。（最大延迟为 wal_writer_delay 的三倍。）与 fsync 不同，将此参数设为off不会带来数据库不一致的风险：操作系统或数据库崩溃可能会使一些最近报告已提交的事务丢失，但数据库状态会与这些事务已正常中止时完全相同。因此，当性能比完全确保事务持久性更重要时，关闭synchronous_commit可以是一种有用的替代方案。更多讨论见第 30.3 节。如果 synchronous_standby_names 非空，
synchronous_commit还控制事务提交是否等待备库处理其 WAL 记录。设为
remote_apply时，提交会等待当前同步备库回复，确认已收到并应用该事务的提交记录，使其对备库上的查询可见，并且已将其写入备库的持久存储。由于需要等待 WAL 重放，这会比之前的设置产生大得多的提交延迟。设为on时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其刷写到持久存储。这能保证事务不会丢失，除非主库和所有同步备库的数据库存储都损坏。设为remote_write时，提交会等待当前同步备库回复，确认已收到事务的提交记录，并已将其写入各自的文件系统。此设置能保证备库上的 PostgreSQL 实例崩溃时数据不丢失，但不能保证备库发生操作系统级别崩溃时数据不丢失，因为数据未必已写入备库的持久存储。设为local时，提交会等待本地刷盘，但不等待复制。使用同步复制时通常不希望采用这种设置，提供它是为了使选项完整。此参数可以随时更改；每个事务的行为由提交时生效的设置决定。因此，让一些事务同步提交、另一些事务异步提交是可行且有用的。例如，当默认设置要求同步提交时，可以在一个包含多条语句的事务中执行
SET LOCAL synchronous_commit TO OFF，使该事务异步提交。表 19.1 汇总了
synchronous_commit各种设置具备的能力。表 19.1. synchronous_commit 模式
synchronous_commit 设置 本地提交持久性 PG 崩溃后备库提交持久性 OS 崩溃后备库提交持久性 备库查询一致性 remote_apply • • • • on • • • remote_write • • local • off 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 和 FreeBSD 中的默认值。默认值不一定最合适；可能需要更改此设置或系统配置的其他方面，以确保崩溃时的数据安全或达到最佳性能。这些方面在第 30.1 节中讨论。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。full_page_writes(boolean) #启用此参数时，PostgreSQL 服务器会在检查点之后首次修改每个磁盘页面时，将该页面的全部内容写入 WAL。这样做是因为，操作系统崩溃时正在进行的页面写入可能只完成了一部分，导致磁盘页面混有新旧数据。通常存储在 WAL 中的行级变更数据不足以在崩溃恢复时完整还原这样的页面。保存整页镜像能保证正确恢复页面，但会增加必须写入 WAL 的数据量。（由于 WAL 重放总是从检查点开始，只需在检查点之后首次修改每个页面时这样做。因此，减少整页写入开销的一种方法是增大检查点间隔参数。）
关闭此参数可以加快正常操作，但系统故障后可能出现不可恢复的数据损坏或静默数据损坏。风险与关闭
fsync类似，虽然较小，但也只有在建议关闭fsync的相同情形下，才应关闭此参数。关闭这个选项并不影响用于时间点恢复（PITR）的 WAL 归档使用（见第 25.3 节）。
这个参数只能在
postgresql.conf文件中或在服务器命令行上设置。默认值是on。wal_log_hints(boolean) #当这个参数为
on时，PostgreSQL 服务器在检查点之后首次修改页面时把该磁盘页面的整个内容都写入 WAL，即使对所谓的提示位做非关键修改也会这样做。如果启用了数据校验和，提示位更新总是会被 WAL 记录并且这个设置会被忽略。你可以用这个设置来测试：如果数据库启用数据校验和，会产生多少额外的 WAL 记录。
这个参数只能在服务器启动时设置。默认值是
off。wal_compression(boolean) #当这个参数为
on时，PostgreSQL 服务器在 full_page_writes 打开时或在基础备份期间，压缩写入 WAL 的整页镜像。在 WAL 重放期间将对压缩的整页镜像进行解压。默认值是off。只有超级用户能更改这个设置。开启此参数可以减少 WAL 数据量，而且不会增加不可恢复的数据损坏风险；代价是在记录 WAL 时压缩、重放 WAL 时解压会额外消耗一些 CPU。
wal_buffers(integer) #用于还未写入磁盘的 WAL 数据的共享内存量。默认值 -1 选择等于 shared_buffers 的 1/32 的尺寸（大约 3%），但是不小于
64kB也不大于 WAL 段的尺寸（通常为16MB）。如果自动的选择太大或太小可以手工设置该值，但是任何小于32kB的正值都将被当作32kB。这个参数只能在服务器启动时设置。在每次事务提交时，WAL 缓冲区的内容被写出到磁盘，因此极大的值不太可能带来显著收益。不过，把这个值设置为至少几个兆字节可以在一个繁忙的服务器（其中很多客户端会在同一时间提交）上提高写性能。由默认设置 -1 选择的自动调节将在大部分情况下得到合理的结果。
wal_writer_delay(integer) #指定 WAL 写入器刷写 WAL 的频繁程度。刷写 WAL 之后，它会休眠
wal_writer_delay毫秒，除非被异步提交的事务唤醒。如果上一次刷写距今少于wal_writer_delay毫秒，并且此后产生的 WAL 少于wal_writer_flush_after字节，则只将 WAL 写入操作系统，而不刷写到磁盘。默认值为 200 毫秒（200ms）。请注意，许多系统的休眠延迟有效分辨率为 10 毫秒；将wal_writer_delay设置为非 10 的倍数的值，可能与设置为下一个更大的 10 的倍数具有相同效果。此参数只能在postgresql.conf文件中或在服务器命令行上设置。wal_writer_flush_after(integer) #指定 WAL 写入器刷写 WAL 的频繁程度。如果上一次刷写距今少于
wal_writer_delay毫秒，并且此后产生的 WAL 少于wal_writer_flush_after字节，则只将 WAL 写入操作系统，而不刷写到磁盘。如果wal_writer_flush_after设置为0，则立即刷写 WAL 数据。默认值为1MB。此参数只能在postgresql.conf文件中或在服务器命令行上设置。commit_delay(integer) #设置
commit_delay会在发起 WAL 刷盘之前添加以微秒为单位的时间延迟。如果系统负载足够高，使得在给定时间间隔内有更多事务准备提交，这可以通过允许更多事务通过一次 WAL 刷盘来提高组提交吞吐量。不过，每次 WAL 刷盘的延迟也会因此增加，最多增加commit_delay微秒。如果没有其他事务准备提交，等待就没有意义，因此仅当即将发起刷盘时至少还有commit_siblings个其他活动事务，才会等待。此外，如果禁用了fsync，也不会等待。默认commit_delay为零（无延迟）。只有超级用户能更改这个设置。在 PostgreSQL 的 9.3 发布之前，
commit_delay的行为不同并且效果更差：它只影响提交，而不是所有 WAL 刷写，并且即使 WAL 刷盘更早完成，也会等待整个配置的延迟时间。从 PostgreSQL 9.3 开始，第一个准备好刷写的进程会等待配置的间隔，而后续的进程只等到领先者完成刷写操作。commit_siblings(integer) #执行
commit_delay延迟前要求的并发活动事务的最小数目。大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务。
19.5.2. 检查点 #
checkpoint_timeout(integer) #自动 WAL 检查点之间的最长时间，以秒为单位。合理的范围在 30 秒到 1 天之间。默认是 5 分钟（
5min）。增加这个参数的值可能会增加崩溃恢复所需的时间。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。checkpoint_completion_target(floating point) #指定检查点完成的目标，作为检查点之间总时间的一部分。默认是 0.5。这个参数只能在
postgresql.conf文件中或在服务器命令行上设置。checkpoint_flush_after(integer) #当执行检查点时写入的数据量超过
checkpoint_flush_after字节时，就尝试强制 OS 把这些写发送到底层存储。这样做将会限制内核页面高速缓存中的脏数据数量，降低在检查点末尾发出fsync或者 OS 在后台大批量写回数据时被卡住的可能性。这通常能显著降低事务延迟，但是也有一些情况（特别是负载超过 shared_buffers 但小于 OS 页面高速缓存）的性能会降低。这种设置可能会在某些平台上没有效果。合法的范围在0（禁用强制写回）和2MB之间。Linux 上的默认值是256kB，其他平台上是0（如果BLCKSZ不是 8kB，则默认值和最大值会按比例缩放到它）。这个参数只能在postgresql.conf文件中或者服务器命令行上设置。checkpoint_warning(integer) #如果由于填充检查点段文件导致的检查点之间的间隔低于这个参数表示的秒数，那么就向服务器日志写一个消息（它建议增加
max_wal_size的值）。默认值是 30 秒（30s）。零则关闭警告。如果checkpoint_timeout低于checkpoint_warning，则不会有警告产生。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。max_wal_size(integer) #在自动检查点期间允许 WAL 增长的最大大小。这是一个软限制；在特殊情况下，如重负载、失败的
archive_command，或高wal_keep_segments设置下，WAL 大小可能会超过max_wal_size。默认值为 1 GB。增加此参数可能会增加崩溃恢复所需的时间。此参数只能在postgresql.conf文件或服务器命令行中设置。min_wal_size(integer) #只要 WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是被回收以便未来使用，而不是直接被删除。这可以被用来确保有足够的 WAL 空间被保留来应付 WAL 使用的高峰，例如运行大型的批处理任务。默认是 80 MB。这个参数只能在
postgresql.conf或者服务器命令行中设置。
19.5.3. 归档 #
archive_mode(enum) #当启用
archive_mode时，完成的 WAL 段会通过设置 archive_command 发送到归档存储。除了用于禁用归档的off外，还有两种模式：on和always。在正常操作期间，这两种模式之间没有区别，但当设置为always时，WAL 归档程序在归档恢复或备库模式下也会被启用。在always模式下，从归档中恢复的所有文件或通过流复制传输的文件将被再次归档。详细信息请参见第 26.2.9 节。archive_mode和archive_command是单独的变量，这样archive_command可以在不离开归档模式的情况下进行更改。此参数只能在服务器启动时设置。当wal_level设置为minimal时，无法启用archive_mode。archive_command(string) #本地 shell 命令被执行来归档一个完成的 WAL 文件段。字符串中的任何
%p被替换成要被归档的文件的路径名，而%f只被文件名替换（路径名是相对于服务器的工作目录，即集簇的数据目录）。如果要在命令里嵌入一个真正的%字符，可以使用%%。有一点很重要，该命令只在成功时返回一个零作为退出状态。更多信息请见第 25.3.1 节。这个参数只能在
postgresql.conf文件或服务器命令行中设置。除非在服务器启动时启用了archive_mode，否则将被忽略。如果archive_command是空字符串（默认值），而archive_mode已启用，WAL 归档将暂时被禁用，但服务器将继续积累 WAL 段文件，期望很快会提供命令。将archive_command设置为一个什么都不做但返回 true 的命令，例如/bin/true（Windows 上为REM），实际上禁用了归档，但也破坏了用于归档恢复所需的 WAL 文件链，因此只应在不寻常的情况下使用。archive_timeout(integer) #archive_command 只针对已完成的 WAL 段调用。因此，如果您的服务器生成的 WAL 流量较少（或者在这样做时有间歇期），在事务完成和安全记录到归档存储之间可能会有很长的延迟。为了限制未归档数据的年龄，您可以将
archive_timeout设置为强制服务器定期切换到新的 WAL 段文件。当此参数大于零时，只要自上次段文件切换以来经过了指定的秒数，并且存在任何数据库活动，包括单个检查点（如果没有数据库活动，则跳过检查点），服务器将切换到新的段文件。请注意，由于强制切换而提前关闭的归档文件仍然与完全填满的文件长度相同。因此，使用非常短的archive_timeout是不明智的，它会使您的归档存储膨胀。通常，将archive_timeout设置为一分钟左右是合理的。如果您希望数据比这更快地从主库复制出来，您应该考虑使用流复制而不是归档。此参数只能在postgresql.conf文件或服务器命令行中设置。