支持的版本: 当前 (17) / 16 / 15 / 14 / 13
开发版本: devel
不支持的版本: 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1

19.5. 预写式日志 #

有关调整这些设置的更多信息,请参阅第 28.5 节

19.5.1. 设置 #

wal_level (enum) #

wal_level 确定写入 WAL 的信息量。默认值为 replica,它写入足够的数据以支持 WAL 归档和复制,包括在备用服务器上运行只读查询。minimal 删除除从崩溃或立即关机中恢复所需信息之外的所有日志记录。最后,logical 添加支持逻辑解码所需的信息。每个级别都包含在所有较低级别记录的信息。此参数只能在服务器启动时设置。

minimal 级别生成的 WAL 量最少。它不会为创建或重写它们的事务中的永久关系记录任何行信息。这可以使操作更快(请参阅第 14.4.7 节)。启动此优化的操作包括

ALTER ... SET TABLESPACE
CLUSTER
CREATE TABLE
REFRESH MATERIALIZED VIEW(不带 CONCURRENTLY
REINDEX
TRUNCATE

但是,最小 WAL 不包含用于时间点恢复的足够信息,因此必须使用 replica 或更高级别才能启用连续归档(archive_mode)和流二进制复制。事实上,如果 max_wal_senders 为非零,服务器甚至不会在这种模式下启动。请注意,将 wal_level 更改为 minimal 会使之前的基本备份无法用于时间点恢复和备用服务器。

logical 级别中,记录的信息与 replica 相同,另外还包含从 WAL 中提取逻辑变更集所需的信息。使用 logical 级别将增加 WAL 的量,特别是如果许多表配置为 REPLICA IDENTITY FULL 并且执行了许多 UPDATEDELETE 语句。

在 9.6 之前的版本中,此参数还允许使用值 archivehot_standby。这些仍然被接受,但映射到 replica

fsync (boolean) #

如果此参数为 on,则 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_applyon(默认值)、remote_writelocaloff

如果 synchronous_standby_names 为空,则唯一有意义的设置是 onoffremote_applyremote_writelocal 都提供与 on 相同的本地同步级别。所有非 off 模式的本地行为是等待 WAL 本地刷新到磁盘。在 off 模式下,没有等待,因此当向客户端报告成功时,与稍后保证事务安全以防止服务器崩溃之间可能存在延迟。(最大延迟是 wal_writer_delay 的三倍。)与 fsync 不同,将此参数设置为 off 不会产生任何数据库不一致的风险:操作系统或数据库崩溃可能会导致丢失一些最近据称已提交的事务,但数据库状态将与这些事务已干净中止的状态相同。因此,当性能比对事务持久性的确切确定性更重要时,关闭 synchronous_commit 可以是一个有用的替代方案。有关更多讨论,请参阅第 28.4 节

如果 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 崩溃后的备用持久提交 操作系统崩溃后的备用持久提交 备用查询一致性
remote_apply
开启  
remote_write    
本地      
关闭        

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 文件)

并非所有平台都提供所有这些选项。默认值是上述列表中平台支持的第一个方法,但 fdatasync 是 Linux 和 FreeBSD 上的默认值。默认值不一定是理想的;可能需要更改此设置或系统配置的其他方面,以创建崩溃安全配置或实现最佳性能。这些方面在第 28.1 节中讨论。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

full_page_writes (boolean) #

当此参数开启时,PostgreSQL 服务器在检查点后第一次修改该页时,将每个磁盘页的全部内容写入 WAL。这是必需的,因为在操作系统崩溃期间正在进行的页面写入可能仅部分完成,从而导致磁盘上的页面包含旧数据和新数据的混合。通常存储在 WAL 中的行级更改数据不足以在崩溃后恢复期间完全还原此类页面。存储整个页面映像可保证页面可以正确还原,但代价是必须写入 WAL 的数据量增加。(由于 WAL 重放始终从检查点开始,因此在检查点后每次更改页面时执行此操作就足够了。因此,减少全页写入成本的一种方法是增加检查点间隔参数。)

关闭此参数可以加快正常操作,但可能会在系统故障后导致不可恢复的数据损坏或静默数据损坏。风险与关闭 fsync 类似,尽管较小,并且只有在与该参数推荐的相同情况下才应将其关闭。

关闭此参数不会影响使用 WAL 归档进行时间点恢复 (PITR)(请参阅第 25.3 节)。

此参数只能在 postgresql.conf 文件或服务器命令行中设置。默认值为 on

wal_log_hints (boolean) #

当此参数为 on 时,PostgreSQL 服务器在检查点后第一次修改该页时,将每个磁盘页的全部内容写入 WAL,即使对于所谓的提示位的非关键修改也是如此。

如果启用了数据校验和,则始终记录提示位更新,并且将忽略此设置。您可以使用此设置来测试如果数据库启用了数据校验和,会发生多少额外的 WAL 日志记录。

此参数只能在服务器启动时设置。默认值为 off

wal_compression (enum) #

此参数使用指定的压缩方法启用 WAL 压缩。启用后,当 full_page_writes 为 on 或在基本备份期间,PostgreSQL 服务器将写入 WAL 的完整页面映像进行压缩。压缩的页面映像将在 WAL 重放期间解压缩。支持的方法包括 pglzlz4(如果 PostgreSQL 是使用 --with-lz4 编译的)和 zstd(如果 PostgreSQL 是使用 --with-zstd 编译的)。默认值为 off。只有超级用户和具有相应 SET 权限的用户才能更改此设置。

启用压缩可以减少 WAL 容量,而不会增加不可恢复的数据损坏的风险,但代价是在 WAL 日志记录期间进行压缩以及在 WAL 重放期间进行解压缩会花费一些额外的 CPU。

wal_init_zero (boolean) #

如果设置为 on(默认值),则此选项会导致新的 WAL 文件填充零。在某些文件系统上,这可以确保在我们需要写入 WAL 记录之前分配空间。但是,写入时复制 (COW) 文件系统可能不会从此技术中受益,因此给出了跳过不必要工作的选项。如果设置为 off,则仅在创建文件时写入最后一个字节,使其具有预期的大小。

wal_recycle (boolean) #

如果设置为 on(默认值),则此选项会导致 WAL 文件通过重命名来回收,从而避免创建新文件。在 COW 文件系统上,创建新文件可能会更快,因此提供了禁用此行为的选项。

wal_buffers (integer) #

用于尚未写入磁盘的 WAL 数据的共享内存量。默认设置 -1 选择的大小等于 shared_buffers 的 1/32(约 3%),但不小于 64kB 且不大于一个 WAL 段的大小,通常为 16MB。如果自动选择的大小太大或太小,则可以手动设置此值,但任何小于 32kB 的正值都将被视为 32kB。如果指定此值时没有单位,则将其视为 WAL 块,即 XLOG_BLCKSZ 字节,通常为 8kB。此参数只能在服务器启动时设置。

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 数据。如果指定此值时没有单位,则将其视为 WAL 块,即 XLOG_BLCKSZ 字节,通常为 8kB。默认值为 1MB。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

wal_skip_threshold (integer) #

wal_levelminimal 并且事务在创建或重写永久关系后提交时,此设置确定如何持久化新数据。如果数据小于此设置,则将其写入 WAL 日志;否则,请使用受影响文件的 fsync。根据您的存储属性,如果此类提交正在减慢并发事务的速度,则提高或降低此值可能会有所帮助。如果指定此值时没有单位,则将其视为千字节。默认值为 2 兆字节 (2MB)。

commit_delay (integer) #

设置 commit_delay 会在启动 WAL 刷新之前添加时间延迟。如果系统负载足够高,使得其他事务在给定的间隔内准备好提交,则这可以通过允许更多事务通过单个 WAL 刷新来提交来提高组提交吞吐量。但是,它也会使每个 WAL 刷新的延迟增加到 commit_delay。由于如果没有其他事务准备好提交,则延迟只是浪费,因此只有当在即将启动刷新时至少有 commit_siblings 其他事务处于活动状态时,才会执行延迟。此外,如果禁用 fsync,则不会执行任何延迟。如果指定此值时没有单位,则将其视为微秒。默认的 commit_delay 为零(无延迟)。只有超级用户和具有相应 SET 权限的用户才能更改此设置。

PostgreSQL 9.3 之前的版本中,commit_delay 的行为有所不同,效果也远不如现在:它只影响提交操作,而不是所有的 WAL 刷新操作,并且即使 WAL 刷新提前完成,也会等待配置的整个延迟时间。从 PostgreSQL 9.3 开始,第一个准备好刷新的进程会等待配置的时间间隔,而后续的进程只等待领导者完成刷新操作即可。

commit_siblings (integer) #

执行 commit_delay 延迟之前需要的最少并发打开事务数。较大的值会使在延迟间隔期间至少有一个其他事务准备好提交的可能性更高。默认值为五个事务。

19.5.2. 检查点 #

checkpoint_timeout (integer) #

自动 WAL 检查点之间的最大时间。如果此值没有指定单位,则以秒为单位。有效范围为 30 秒到一天之间。默认值为五分钟 (5min)。增加此参数会增加崩溃恢复所需的时间。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

checkpoint_completion_target (浮点数) #

指定检查点完成的目标,作为检查点之间总时间的分数。默认值为 0.9,它将检查点分散到几乎所有可用的时间间隔中,从而提供相当一致的 I/O 负载,同时也为检查点完成开销留出一些时间。不建议减少此参数,因为它会导致检查点更快完成。这将导致在检查点期间有更高的 I/O 率,然后在检查点完成和下一个计划检查点之间有一段时间的较低 I/O 率。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

checkpoint_flush_after (integer) #

每当在执行检查点时写入的数据量超过此值时,尝试强制操作系统将这些写入发送到基础存储。这样做将限制内核页面缓存中脏数据的数量,从而降低在检查点结束时发出 fsync 或操作系统在后台以更大的批量写回数据时出现延迟的可能性。通常,这将导致事务延迟大大减少,但也有一些情况,尤其是对于大于 shared_buffers 但小于操作系统页面缓存的工作负载,性能可能会下降。此设置在某些平台上可能无效。如果此值未指定单位,则以块为单位,即 BLCKSZ 字节,通常为 8kB。有效范围介于 0(禁用强制写回)和 2MB 之间。默认值在 Linux 上为 256kB,在其他地方为 0。(如果 BLCKSZ 不是 8kB,则默认值和最大值会按比例缩放。)此参数只能在 postgresql.conf 文件或服务器命令行中设置。

checkpoint_warning (integer) #

如果因 WAL 段文件填充而导致的检查点发生的时间间隔小于此值,则向服务器日志写入消息(这表明应该增加 max_wal_size)。如果此值没有指定单位,则以秒为单位。默认值为 30 秒 (30s)。零禁用警告。如果 checkpoint_timeout 小于 checkpoint_warning,则不会生成警告。此参数只能在 postgresql.conf 文件或服务器命令行中设置。

max_wal_size (integer) #

在自动检查点期间允许 WAL 增长的最大大小。这是一个软限制;在特殊情况下,例如高负载、失败的 archive_commandarchive_library 或较高的 wal_keep_size 设置下,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 时,通过设置 archive_commandarchive_library,已完成的 WAL 段将发送到归档存储。除了 off(禁用)之外,还有两种模式:onalways。在正常操作期间,这两种模式没有区别,但当设置为 always 时,WAL 归档器也会在归档恢复或备用模式期间启用。在 always 模式下,从归档恢复或通过流复制流式传输的所有文件都将(再次)归档。有关详细信息,请参见 第 26.2.9 节

archive_mode 是一个与 archive_commandarchive_library 分开的设置,以便可以在不离开归档模式的情况下更改 archive_commandarchive_library。此参数只能在服务器启动时设置。当 wal_level 设置为 minimal 时,无法启用 archive_mode

archive_command (字符串) #

执行以归档已完成的 WAL 文件段的本地 shell 命令。字符串中的任何 %p 都将替换为要归档的文件的路径名,任何 %f 都将替换为仅文件名。(路径名相对于服务器的工作目录,即集群的数据目录。)使用 %% 在命令中嵌入实际的 % 字符。重要的是,该命令仅在成功时才返回零退出状态。有关更多信息,请参见 第 25.3.1 节

此参数只能在 postgresql.conf 文件或服务器命令行中设置。只有在服务器启动时启用了 archive_mode 并且 archive_library 设置为空字符串时才会使用它。如果同时设置了 archive_commandarchive_library,则会引发错误。如果启用了 archive_mode(并且 archive_library 设置为空字符串),而 archive_command 是一个空字符串(默认值),则 WAL 归档将暂时禁用,但服务器会继续累积 WAL 段文件,以期望很快会提供命令。将 archive_command 设置为仅返回 true 的命令,例如 /bin/true(在 Windows 上为 REM),实际上会禁用归档,但也会破坏归档恢复所需的 WAL 文件链,因此仅应在不寻常的情况下使用。

archive_library (字符串) #

用于归档已完成的 WAL 文件段的库。如果设置为空字符串(默认值),则启用通过 shell 进行的归档,并使用 archive_command。如果同时设置了 archive_commandarchive_library,则会引发错误。否则,将使用指定的共享库进行归档。当此参数更改时,postmaster 会重新启动 WAL 归档器进程。有关更多信息,请参见 第 25.3.1 节第 49 章

此参数只能在 postgresql.conf 文件或服务器命令行中设置。

archive_timeout (integer) #

只有当 WAL 段完成后,才会调用 archive_commandarchive_library。因此,如果您的服务器生成的 WAL 流量很少(或者在空闲期间很少生成),那么从事务完成到安全地记录在归档存储中之间可能会有很长的延迟。为了限制未归档数据的最长时间,您可以设置 archive_timeout 以强制服务器定期切换到新的 WAL 段文件。当此参数大于零时,服务器将在自上次段文件切换以来经过此时间量后,并且发生任何数据库活动(包括单次检查点,如果没有数据库活动则跳过检查点)时,切换到新的段文件。请注意,由于强制切换而提前关闭的归档文件仍然与完全填充的文件长度相同。因此,使用非常短的 archive_timeout 是不明智的,这会使您的归档存储膨胀。archive_timeout 设置为一分钟左右通常是合理的。如果您希望数据比这更快地从主服务器复制出去,则应考虑使用流复制而不是归档。如果此值未指定单位,则视为秒。此参数只能在 postgresql.conf 文件中或服务器命令行上设置。

19.5.4. 恢复 #

本节描述适用于一般恢复的设置,影响崩溃恢复、流复制和基于归档的复制。

recovery_prefetch (enum) #

在恢复期间,是否尝试预取 WAL 中引用但尚未在缓冲区池中的块。有效值为 offontry(默认值)。设置 try 仅当操作系统提供 posix_fadvise 函数时才启用预取,该函数目前用于实现预取。请注意,某些操作系统提供了该函数,但它不执行任何操作。

预取即将需要的块可以减少某些工作负载的恢复期间的 I/O 等待时间。另请参阅 wal_decode_buffer_sizemaintenance_io_concurrency 设置,它们限制预取活动。

wal_decode_buffer_size (integer) #

服务器在 WAL 中查找要预取的块时可以提前查看的最大距离。如果此值未指定单位,则视为字节。默认值为 512kB。

19.5.5. 归档恢复 #

本节描述仅在恢复期间应用的设置。它们必须为您希望执行的任何后续恢复进行重置。

恢复 包括将服务器用作备用服务器或执行目标恢复。通常,备用模式用于提供高可用性和/或读取可扩展性,而目标恢复用于从数据丢失中恢复。

要在备用模式下启动服务器,请在数据目录中创建一个名为 standby.signal 的文件。服务器将进入恢复状态,并且当达到归档 WAL 的末尾时不会停止恢复,而是会通过连接到 primary_conninfo 设置指定的发送服务器和/或使用 restore_command 获取新的 WAL 段来继续尝试恢复。对于此模式,本节和 第 19.6.3 节 中的参数是相关的。 第 19.5.6 节 中的参数也将被应用,但通常在此模式下不起作用。

要在目标恢复模式下启动服务器,请在数据目录中创建一个名为 recovery.signal 的文件。如果同时创建了 standby.signalrecovery.signal 文件,则备用模式优先。当归档的 WAL 完全重放,或达到 recovery_target 时,目标恢复模式结束。在此模式下,将使用本节和 第 19.5.6 节 中的参数。

restore_command (string) #

用于检索 WAL 文件序列的归档段的本地 shell 命令。此参数对于归档恢复是必需的,但对于流复制是可选的。字符串中的任何 %f 都将替换为要从归档中检索的文件的名称,任何 %p 都将替换为服务器上的复制目标路径名。(路径名相对于当前工作目录,即集群的数据目录。)任何 %r 都将替换为包含最后一个有效重启点的文件的名称。那是必须保留的最早文件,以允许恢复是可重启的,因此可以使用此信息将归档截断为仅支持从当前恢复重启所需的最小值。%r 通常仅由热备用配置使用(请参阅 第 26.2 节)。写入 %% 以嵌入实际的 % 字符。

该命令仅在成功时才返回零退出状态非常重要。该命令被要求提供归档中不存在的文件名;当被询问时,它必须返回非零值。例子

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows

例外情况是,如果命令因信号(SIGTERM 除外,该信号用作数据库服务器关闭的一部分)或 shell 错误(例如找不到命令)而终止,则恢复将中止,服务器将不会启动。

此参数只能在 postgresql.conf 文件或服务器命令行中设置。

archive_cleanup_command (string) #

此可选参数指定将在每个重启点执行的 shell 命令。 archive_cleanup_command 的目的是提供一种机制来清理备用服务器不再需要的旧归档 WAL 文件。任何 %r 都将替换为包含最后一个有效重启点的文件的名称。那是必须保留的最早文件,以允许恢复是可重启的,因此可以安全地删除早于 %r 的所有文件。可以使用此信息将归档截断为仅支持从当前恢复重启所需的最小值。 pg_archivecleanup 模块通常在单备用配置的 archive_cleanup_command 中使用,例如

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'

但请注意,如果多个备用服务器正在从同一个归档目录恢复,则您需要确保在任何服务器都不再需要 WAL 文件之前不删除它们。archive_cleanup_command 通常在热备用配置中使用(请参阅 第 26.2 节)。在命令中写入 %% 以嵌入实际的 % 字符。

如果命令返回非零退出状态,则将写入警告日志消息。例外情况是,如果该命令被信号或 shell 错误(例如未找到命令)终止,则会引发致命错误。

此参数只能在 postgresql.conf 文件或服务器命令行中设置。

recovery_end_command (string) #

此参数指定在恢复结束时仅执行一次的 shell 命令。此参数是可选的。 recovery_end_command 的目的是为复制或恢复后清理提供机制。任何 %r 都将替换为包含最后一个有效重启点的文件的名称,如 archive_cleanup_command 中所示。

如果该命令返回非零退出状态,则将写入警告日志消息,并且数据库仍将继续启动。例外情况是,如果该命令被信号或 shell 错误(例如未找到命令)终止,则数据库将不会继续启动。

此参数只能在 postgresql.conf 文件或服务器命令行中设置。

19.5.6. 恢复目标 #

默认情况下,恢复将恢复到 WAL 日志的末尾。以下参数可用于指定较早的停止点。最多可以使用一个 recovery_targetrecovery_target_lsnrecovery_target_namerecovery_target_timerecovery_target_xid;如果在配置文件中指定了多个,则会引发错误。这些参数只能在服务器启动时设置。

recovery_target = 'immediate' #

此参数指定恢复应在达到一致状态后立即结束,即尽可能早地结束。从在线备份还原时,这意味着获取备份结束的点。

从技术上讲,这是一个字符串参数,但目前只允许使用 'immediate' 值。

recovery_target_name (string) #

此参数指定恢复将继续进行到的已命名还原点(使用 pg_create_restore_point() 创建)。

recovery_target_time (timestamp) #

此参数指定恢复将继续进行到的时间戳。精确的停止点也受 recovery_target_inclusive 的影响。

此参数的值是 timestamp with time zone 数据类型接受的相同格式的时间戳,但您不能使用时区缩写(除非 timezone_abbreviations 变量已在配置文件中较早设置)。首选样式是使用与 UTC 的数字偏移量,或者您可以写入完整的时区名称,例如,Europe/Helsinki 而不是 EEST

recovery_target_xid (string) #

此参数指定恢复将继续进行到的事务 ID。请记住,虽然事务 ID 在事务开始时按顺序分配,但事务可以按不同的数字顺序完成。将恢复的事务是在指定的事务之前(并且可以选择包括)提交的事务。精确的停止点也受 recovery_target_inclusive 的影响。

recovery_target_lsn (pg_lsn) #

此参数指定恢复将继续进行到的预写日志位置的 LSN。精确的停止点也受 recovery_target_inclusive 的影响。此参数使用系统数据类型 pg_lsn 进行解析。

以下选项进一步指定恢复目标,并影响达到目标时发生的情况

recovery_target_inclusive (boolean) #

指定是在指定的恢复目标之后立即停止(on),还是在恢复目标之前停止(off)。当指定了 recovery_target_lsnrecovery_target_timerecovery_target_xid 时适用。此设置控制是否将具有精确目标 WAL 位置(LSN)、提交时间或事务 ID 的事务包括在恢复中。默认值为 on

recovery_target_timeline (string) #

指定恢复到特定的时间线。该值可以是数字时间线 ID 或特殊值。值 current 沿着拍摄基本备份时当前的时间线进行恢复。值 latest 恢复到归档中找到的最新时间线,这在备用服务器中非常有用。latest 是默认值。

要以十六进制指定时间线 ID(例如,如果从 WAL 文件名或历史文件中提取),请在其前面加上 0x。例如,如果 WAL 文件名为 00000011000000A10000004F,则时间线 ID 为 0x11(或十进制的 17)。

通常,您只需要在复杂的重新恢复情况下设置此参数,在这些情况下,您需要返回到在时间点恢复之后达到的状态。有关讨论,请参见第 25.3.6 节

recovery_target_action (enum) #

指定服务器在达到恢复目标后应采取的操作。默认值为 pause,这意味着恢复将暂停。promote 表示恢复过程将完成,服务器将开始接受连接。最后,shutdown 将在达到恢复目标后停止服务器。

pause 设置的预期用途是允许针对数据库执行查询,以检查此恢复目标是否是最佳恢复点。可以使用 pg_wal_replay_resume() 恢复暂停状态(请参阅表 9.97),然后导致恢复结束。如果此恢复目标不是所需的停止点,则关闭服务器,将恢复目标设置更改为稍后的目标,然后重新启动以继续恢复。

shutdown 设置有助于使实例在所需的精确重放点准备就绪。实例仍然能够重放更多的 WAL 记录(实际上,它必须在下次启动时重放自上次检查点以来的 WAL 记录)。

请注意,当 recovery_target_action 设置为 shutdown 时,recovery.signal 不会被删除,因此除非更改配置或手动删除 recovery.signal 文件,否则任何后续启动都将以立即关闭结束。

如果没有设置恢复目标,则此设置无效。如果未启用 hot_standby,则 pause 设置的作用与 shutdown 相同。如果在提升正在进行时达到恢复目标,则 pause 设置的作用与 promote 相同。

在任何情况下,如果配置了恢复目标,但归档恢复在达到目标之前结束,则服务器将因致命错误而关闭。

19.5.7. WAL 摘要 #

这些设置控制 WAL 摘要,这是执行增量备份必须启用的功能。

summarize_wal (boolean) #

启用 WAL 摘要器进程。请注意,WAL 摘要可以在主服务器或备用服务器上启用。此参数只能在 postgresql.conf 文件或服务器命令行中设置。默认值为 off

如果 wal_level 设置为 minimal,则服务器无法以 summarize_wal=on 启动。如果在服务器启动后配置 summarize_wal=on,而 wal_level=minimal,则摘要器将运行,但拒绝为任何使用 wal_level=minimal 生成的 WAL 生成摘要文件。

wal_summary_keep_time (integer) #

配置 WAL 摘要器自动删除旧 WAL 摘要的时间长度。文件时间戳用于确定哪些文件足够旧可以删除。通常,您应将其设置得比备份和稍后依赖它的增量备份之间可能经过的时间长得多。WAL 摘要必须在之前的备份和正在进行的新备份之间的整个 WAL 记录范围内可用;否则,增量备份将失败。如果此参数设置为零,则不会自动删除 WAL 摘要,但手动删除您知道未来增量备份不需要的文件是安全的。此参数只能在 postgresql.conf 文件或服务器命令行中设置。如果此值在没有单位的情况下指定,则将其视为分钟。默认值为 10 天。如果 summarize_wal = off,则无论此参数的值如何,都不会删除现有的 WAL 摘要,因为 WAL 摘要器不会运行。

提交更正

如果您发现文档中有任何不正确、与特定功能的体验不符或需要进一步澄清的地方,请使用此表格报告文档问题。