Postgresql 中文操作指南

20.5. Write Ahead Log #

有关调整这些设置的更多信息,请参见 Section 30.5

20.5.1. Settings #

  • wal_level (enum) #

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

    • _minimal_级别产生最少的 WAL 量。它不记录创建或重写它们的事务中永续关系的行信息。这可以使操作速度更快(见 Section 14.4.7)。引发此优化的操作包括:

    • 但是,最小 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) #

    • 如果此参数打开,PostgreSQL 服务器会尝试确保更新通过发出 _fsync()_系统调用或各种等效方法(见 wal_sync_method)物理写入磁盘。这确保数据库集群在操作系统或硬件崩溃后可以恢复到一致的状态。

    • 尽管关闭 fsync 通常会带来性能优势,但如果发生电源故障或系统崩溃,则可能导致无法恢复的数据损坏。因此,只有您能轻松地从外部数据重新创建整个数据库时,才建议关闭 fsync

    • 关闭 fsync 的安全情况的示例包括使用备份文件对新数据库集群进行初始加载、使用数据库集群处理一批将在之后舍弃和重新创建的数据库,或对于频繁重新创建且不用于故障转移的只读数据库克隆。仅仅是高质量硬件不足以成为关闭 fsync 的充分理由。

    • 为了在将 fsync 从关切换换为启用时进行可靠恢复,有必要强制内核中的所有已修改缓冲区进入耐用存储。这可以在关闭集群时或通过运行 fsync、运行 initdb --sync-only、卸载文件系统或重新启动服务器来执行此操作,同时 fsync 已启用。

    • 在许多情况下,对于非关键事务,关闭 synchronous_commit可以提供关闭 _fsync_的潜在性能优势,而不会出现数据损坏的风险。

    • _fsync_只能在 _postgresql.conf_文件中或在服务器命令行中设置。关闭此参数时,还要考虑关闭 full_page_writes

  • synchronous_commit (enum) #

    • 指定数据库服务器在向客户端返回“成功”指示之前必须完成多少 WAL 处理。有效值是 remote_applyon(默认值)、remote_writelocaloff

    • 如果 synchronous_standby_names_为空,则唯一有意义的设置是 _on_和 _offremote_apply,_remote_write_和 _local_都提供与 _on_相同的本地同步级别。所有非-_off_模式的本地行为是等待 WAL 的本地刷新到磁盘。在 _off_模式下,没有等待,因此客户端报告成功的时间和稍后保证该事务对服务器崩溃是安全的的时间之间可能会有延迟。(最大延迟是 wal_writer_delay的三倍。)与 fsync不同,将此参数设置为 _off_不会造成数据库不一致的风险:操作系统或数据库崩溃可能导致一些最近据称已提交的事务丢失,但数据库状态将与这些事务已完成一样整洁地中止。因此,当性能比交易耐用性的确切确定性更重要时,关闭 _synchronous_commit_可能是很有用的替代方案。有关更多讨论,请参见 Section 30.4

    • 如果 synchronous_standby_names不为空,_synchronous_commit_还控制事务提交是否在其 WAL 记录在备用服务器上处理。

    • 将此设置设为 remote_apply 时,提交将等待当前同步备用服务器的答复,表示它们已接收该事务的提交记录并将其应用,这样该记录将对备用服务器上的查询可见,并已写入备用服务器的耐用存储。由于等待 WAL 重放,这将导致比以前设置更大的提交延迟。当设置为 on 时,提交等待当前同步备用服务器的答复,表示它们已接收该事务的提交记录并将该记录刷新到耐用存储中。这确保除非主用服务器和所有同步备用服务器的数据库存储都损坏,否则该事务将不会丢失。当设置为 remote_write 时,提交将等待当前同步备用服务器的答复,表示它们已接收该事务的提交记录并将其写入文件系统。此设置确保在 PostgreSQL 的备用实例崩溃时(但备用服务器不会遭受操作系统级崩溃时,因为数据不一定已到达备用服务器上的耐用存储)可以保留数据。设置 local 使提交等待本地刷新到磁盘,但不会等待复制。在使用同步复制时,通常不希望这样,但这样做是为了完整性。

    • 此参数可以随时更改;任何一个事务的行为由提交时生效的设置确定。因此,可以且有用的是让某些事务同步提交,而其他事务异步提交。例如,要在默认值为相反时使单个多语句事务异步提交,请在事务中发出 SET LOCAL synchronous_commit TO OFF

    • Table 20.1总结了 _synchronous_commit_设置的功能。

  • wal_sync_method (enum) #

    • 用于将 WAL 更新强制写入磁盘的方法。如果 fsync 已关闭,则此设置无关紧要,因为根本不会强制 WAL 文件更新。可能的值有:

    • 并非所有这些选项在所有平台上都可用。默认值是平台支持的上表中的第一个方法,但 _fdatasync_是 Linux 和 FreeBSD 上的默认值。默认值不一定理想;为了创建防崩溃配置或实现最佳性能,可能有必要更改此设置或系统配置的其他方面。这些方面在 Section 30.1中进行了讨论。此参数只能在 _postgresql.conf_文件或服务器命令行中设置。

  • full_page_writes (boolean) #

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

    • 关闭此参数会加速正常操作,但在系统故障后可能会导致无法恢复的数据损坏或静默数据损坏。风险类似于关闭 fsync,尽管较小,并且应仅基于建议用于该参数的相同情况来关闭它。

    • 关闭此参数不会影响使用 WAL 归档进行时间点恢复 (PITR)(请参见 Section 26.3)。

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

  • wal_log_hints (boolean) #

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

    • 如果启用数据校验和,提示位更新总是记录在 WAL 中,此设置将被忽略。您可以使用此设置测试如果您的数据库启用了数据校验和,会出现多少额外的 WAL 记录。

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

  • wal_compression (enum) #

    • 此参数利用指定的压缩方法启用 WAL 压缩。启用后,当 full_page_writes 启用或在基本备份期间,PostgreSQL 服务器会压缩写入 WAL 的全页镜像。压缩页镜像将在 WAL 重放期间解压缩。支持的方法有 pglzlz4 (如果使用 —​with-lz4 编译了 PostgreSQL)、 zstd (如果使用 —​with-zstd 编译了 PostgreSQL)。默认值为 off 。只有超级用户和具有相应 SET 权限的用户可以更改此设置。

    • 启用压缩可以在不增加无法恢复的数据损坏的风险的情况下减少 WAL 卷,但是代价是一些额外的 CPU 在 WAL 记录期间用于压缩和在 WAL 回放期间用于解压缩。

  • wal_init_zero (boolean) #

    • 如果设置为 on(默认值),此选项将使新的 WAL 文件填充为零。在某些文件系统上,这可确保在我们写入 WAL 记录之前分配空间。但是,Copy-On-Write(COW)文件系统可能不会受益于此技术,因此提供了跳过不必要工作的选项。如果设置为 off,则仅在创建文件时写入最后一个字节,使其具有预期的尺寸。

  • wal_recycle (boolean) #

    • 如果设置为 on(默认值),此选项将使 WAL 文件通过重命名进行回收,避免创建新文件的需要。在 COW 文件系统上,创建新的文件可能更快,因此提供了禁用此行为的选项。

  • wal_buffers (integer) #

    • 用于尚未写入磁盘的 WAL 数据的共享内存量。默认设置 -1 选择等于 1/32nd(约 3%) shared_buffers的大小,但不少于 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 权限的用户才能更改此设置。

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

  • commit_siblings (integer) #

    • 在执行 commit_delay 延迟之前所需的最小并发打开事务数。较大的值使得在延迟间隔内至少会有一个其他事务准备好提交的可能性更大。默认值是 5 个事务。

Table 20.1. synchronous_commit Modes

synchronous_commit setting

local durable commit

PG 崩溃后备用持久提交

操作系统崩溃后备用持久提交

standby query consistency

remote_apply

on

remote_write

local

off

20.5.2. Checkpoints #

  • checkpoint_timeout (integer) #

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

  • checkpoint_completion_target (floating point) #

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

  • checkpoint_flush_after (integer) #

    • 在执行检查点时写入的数据量超过此数量后,尝试强制操作系统向基础存储发出这些写入内容。这么做将限制内核页高速缓存中的脏数据量,从而降低在检查点结束时发出 fsync ,或当操作系统写入较大批次数据时在后台造成中断的可能性。通常,这将大大减少事务延迟,但也有一些情况,特别是当工作负载大于 shared_buffers 但小于操作系统的页面缓存时,性能可能会下降。此设置对某些平台可能无效。如果未指定此值单位,则将其视为块,即 BLCKSZ 字节,通常为 8kB。有效范围介于禁用强制写回的 02MB 之间。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 增长的最大大小。这是软限制;WAL 大小可能在特殊情况下(如重负载、archive_commandarchive_library 故障,或 wal_keep_size 设置过高)时超过 max_wal_size。如果未指定此值单位,则取值为兆字节。默认值为 1 GB。增加此参数可能会增加故障恢复所需的时间。此参数只能在 postgresql.conf 文件中或在服务器命令行上设置。

  • min_wal_size (integer) #

    • 只要 WAL 磁盘使用率低于此设置,旧 WAL 文件在检查点时将始终被回收以供将来使用,而不是被移除。这可用于确保保留足够的 WAL 空间来处理 WAL 使用率的峰值,例如运行大型批处理作业时。如果未指定此值单位,则取值为兆字节。默认值为 80 MB。此参数只能在 postgresql.conf 文件中或在服务器命令行上设置。

20.5.3. Archiving #

  • archive_mode (enum) #

    • 当启用“archive_mode”时,通过设置“ archive_command”或“ archive_library”,完成的 WAL 段会被发送到归档存储空间。除了“off”之外,还有两种禁用模式:“on”和“always”。在正常操作期间,这两种模式没有区别,但如果设置为“always”,则 WAL 归档器在归档恢复或备用模式期间也会启用。在“always”模式下,从归档中恢复的所有文件或通过流复制流式传输的所有文件都将再次进行归档。有关详细信息,请参见“ Section 27.2.9”。

    • archive_modearchive_commandarchive_library 的独立设置,以便可以在不离开存档模式的情况下更改 archive_commandarchive_library。此参数只能在服务器启动时设置。当 wal_level 设置为 minimal 时,无法启用 archive_mode

  • archive_command (string) #

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

    • 此参数只能在 postgresql.conf 文件中或在服务器命令行上设置。仅在服务器启动时启用 archive_mode 并且 archive_library 设置为空字符串时才会使用它。如果 archive_commandarchive_library 同时设置,则会引发错误。如果 archive_command 为空字符串(默认值),而 archive_mode 却已启用(并且 archive_library 设置为空字符串),则 WAL 存档将被暂时禁用,但服务器会继续累积 WAL 段文件,期待很快将提供一个命令。将 archive_command 设置为一个什么都不做的命令,例如 /bin/true(Windows 上的 REM),将有效禁用存档,但也将中断存档恢复所需的 WAL 文件链,因此仅应在特殊情况下使用它。

  • archive_library (string) #

    • 用于归档已完成 WAL 文件段的库。如果设置为一个空字符串(默认值),则会启用通过 shell 进行归档,且会使用“ archive_command”。如果“archive_command”和“archive_library”均已设置,则会引发一个错误。否则,将使用指定共享库进行归档。此参数发生更改时,WAL 归档器进程将由协调器重新启动。有关详细信息,请参见“ Section 26.3.1”和“ Chapter 51”。

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

  • archive_timeout (integer) #

    • archive_command”或“ archive_library”仅对已完成的 WAL 段调用。因此,如果你的服务器生成了少量 WAL 流量(或在此期间有空闲时间),则事务完成和在归档存储空间中安全记录之间可能会存在较长的延迟。为了限制未归档数据的陈旧程度,你可以设置“archive_timeout”以强制服务器定期切换到一个新的 WAL 段文件。当此参数大于 0 时,此服务器会在上次段文件切换后经过此时间量,并且有任何数据库活动(包括单次检查点)发生时,切换到一个新的段文件(如果没有任何数据库活动,则会跳过检查点)。请注意,由于强制切换而提前关闭的归档文件仍与完全填满的文件长度相同。因此,不建议使用很短的“archive_timeout”,因为它会导致归档存储空间膨胀。“archive_timeout”设置为一分钟左右通常是合理的。如果你希望以比此更快的速度将数据从主服务器复制出去,则应该考虑使用流复制,而不是归档。如果未指定单位,则此值将视为秒。此参数只能在“postgresql.conf”文件中设置或在服务器命令行中设置。

20.5.4. Recovery #

本部分介绍了适用于一般恢复(影响故障恢复、流复制和基于存档的复制)的设置。

  • recovery_prefetch (enum) #

    • 是否尝试在恢复期间预取尚未进入缓冲池但存在于 WAL 中的块的引用。有效值为 offontry (默认值)。如果操作系统提供了 posix_fadvise 函数,则设置 try 才会启用预取,该函数当前用于实现预取。请注意,某些操作系统提供了该函数,但它没有任何作用。

    • 预取即将需要的块可以减少使用某些工作负载进行恢复期间的 I/O 等待时间。另请参见“ wal_decode_buffer_size”和“ maintenance_io_concurrency”设置,这些设置限制了预取活动。

  • wal_decode_buffer_size (integer) #

    • 服务器可在 WAL 中查找以找到要预取的块的限度。如果未指定此值单位,则取值为字节。默认值为 512 kB。

20.5.5. Archive Recovery #

本部分仅介绍在恢复期间适用的设置。必须将它们重置,以便执行您希望执行的任何后续恢复。

“恢复”范围包括使用该服务器作为备用或为执行目标恢复。通常,备用模式用于提供高可用性和/或读取可伸缩性,而目标恢复用于从数据丢失中恢复。

若要以备用模式启动服务器,请在数据目录中创建一个名为“standby.signal”的文件。该服务器将进入恢复模式,且不会在到达归档 WAL 的末尾时停止恢复,而是会不断尝试通过连接到发送服务器(通过“primary_conninfo”设置指定)和/或使用“restore_command”获取新的 WAL 段来继续恢复。对于此模式,“此部分中的参数”和“ Section 20.6.3”很有用。“ Section 20.5.6”中的参数也将生效,但在该模式中通常没有用。

若要以目标恢复模式启动服务器,请在数据目录中创建一个名为“recovery.signal”的文件。如果同时创建了“standby.signal”文件和“recovery.signal”文件,则备用模式将优先。在已完全重新执行归档 WAL 或达到“recovery_target”时,目标恢复模式将结束。在此模式下,“此部分”和“ Section 20.5.6”中的参数都将生效。

  • restore_command (string) #

    • 要提取 WAL 文件系列的存档段要执行的本地 shell 命令。此参数对于存档恢复是必需的,但对于流复制则是可选的。字符串中的任何 %f 都由从存档中检索的文件的名称替换,任何 %p 都由服务器上的复制目标路径名替换。(路径名相对于当前的工作目录,即集群数据目录。)任何 %r 都由包含最后一个有效重启点的文件的名称替换。这是必须保留的最早的文件,以允许重新启动恢复,因此此信息可用于将存档截断为仅支持从当前恢复重新启动所需的最小文件。 %r 通常只在 warm standby 配置中使用(见 Section 27.2 )。写入 %% 以嵌入实际的 % 字符。

    • *命令仅在成功时才返回零退出状态非常重要。可以为 will 命令指定档案中不存在的文件名;在这样要求时,它必须返回非零值。示例:

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 都由包含最后一个有效重启点的文件的名称替换。这是必须 kept 的最早文件,以允许重新启动恢复,因此所有早于 %r 的文件都可以安全删除。此信息可用于将存档截断为仅支持从当前恢复重新启动所需的最小文件。 pg_archivecleanup 模块通常在 archive_cleanup_command 中用于单备用配置,例如:

archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
  • 但是,请注意,如果多个备用服务器从同一个归档目录进行恢复,则你需要确保在不再被任何服务器需要时才删除 WAL 文件。“archive_cleanup_command”通常用于热备用配置(请参阅“ Section 27.2”)。写入“%%”以在命令中嵌入一个实际的“%”字符。

  • 如果命令返回一个非零的退出状态那么会写入一条警告日志消息。但是,如果命令因一个信号或 shell 出现错误(例如命令未找到)而终止,那么会引发一个致命错误。

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

    • recovery_end_command (string) #

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

  • 如果命令返回一个非零的退出状态,那么会写入一条警告日志消息,无论如何数据库都将继续启动。但是,如果命令因一个信号或 shell 出现错误(例如命令未找到)而终止,那么数据库将不会继续启动。

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

20.5.6. Recovery Target #

默认情况下,恢复将恢复到 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_lsn”、“ recovery_target_time”或“ recovery_target_xid”时,此设置生效。此设置控制是否将具有与目标 WAL 位置(LSN)、提交时间或事务 ID(分别)完全相同的值的事务包括在恢复中。默认值为“on”。

  • recovery_target_timeline (string) #

    • 指定恢复到一个特定时间轴。值可以是一个数字时间轴 ID 或一个特殊值。值 current 沿当时获取基备份时的当前时间轴恢复。值 latest 恢复到归档中找到的最新时间轴,这在备用服务器中很有用。latest 是默认值。

    • 要在十六进制中指定一个时间轴 ID(例如如果从一个 WAL 文件名或历史记录文件中提取出来),那么使用 0x 为其加前缀。例如,如果 WAL 文件名是 00000011000000A10000004F,那么时间轴 ID 是 0x11(或十进制 17)。

    • 通常只在复杂的重新执行恢复情况下才需要设置此参数,在这种情况下,你需要返回到在时间点恢复后才到达的状态。有关讨论,请参见“ Section 26.3.5”。

  • recovery_target_action (enum) #

    • 指定一旦恢复目标达到后,服务器应执行的操作。默认为 pause,这意味着恢复将暂停。promote 表示恢复进程将结束,服务器将开始接受连接。最后,shutdown 将在达到恢复目标后停止服务器。

    • pause”设置的预期用途是允许对数据库执行查询,以检查此恢复目标是否是恢复的最理想点。暂停状态可以通过使用“pg_wal_replay_resume()”(请参见“ Table 9.93”)恢复,从而导致恢复结束。如果此恢复目标不是所需的停止点,则关闭服务器,将恢复目标设置更改为较后的目标,然后重新启动以继续恢复。

    • shutdown 设置有助于在所需的准确重播点准备实例。该实例仍将能够重播更多 WAL 记录(事实上,下次启动时将必须重播自上次检查点以来的 WAL 记录)。

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

    • 如果未设置恢复目标,此设置不生效。如果 hot_standby 未启用,则设置 pauseshutdown 的作用相同。如果在提升进行期间达到恢复目标,则设置 pausepromote 的作用相同。

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