有关调优这些预写式日志设置的更多信息,请参阅 Section 28.5。
wal_level (enum)
#
wal_level 决定向预写式日志(WAL)中写入的物理元数据量等级。默认值为 replica,该级别写入足够多的数据以支持 WAL 归档和流复制,包括在备用服务器上运行只读查询。minimal 会剔除除断电崩溃或立即停机恢复所必需之外的几乎所有日志记录。logical 级别额外增加支持逻辑解码所必需的元数据信息。每个较高级别均包含其下所有级别记录的信息。该参数只能在服务器启动时设置。
minimal 级别产生最小的 WAL 数据量。在创建或重写永久关系的事务中,它完全不记录数据行级别的 WAL 信息。这能显著加快批量写入操作的速度(参见 Section 14.4.7)。触发此优化的操作包括:
ALTER ... SET TABLESPACE |
CLUSTER |
CREATE TABLE |
REFRESH MATERIALIZED VIEW(不带 CONCURRENTLY 选项) |
REINDEX |
TRUNCATE |
然而,minimal 级别的 WAL 并不包含足够的信息用于时间点恢复(PITR),因此必须使用 replica 或更高等级来启用连续归档(archive_mode)和二进制流式复制。事实上,若 max_wal_senders 非零,服务器甚至拒绝在该模式下启动。请注意,将 wal_level 切换为 minimal 会导致此前的所有基础备份无法用于时间点恢复和搭建只读备库。
在 logical 级别中,系统会记录与 replica 完全相同的信息,此外还会额外记录从 WAL 中提取逻辑解码变更集所需的元数据。使用 logical 级别会增加 WAL 日志量,特别是当许多表配置了 REPLICA IDENTITY FULL 且执行了大量的 UPDATE 和 DELETE 语句时。
在 9.6 之前的旧版本中,该参数还允许取值为 archive 和 hot_standby。目前系统仍兼容接受这些取值,但会自动映射为 replica。
fsync (boolean)
#
若此参数开启,PostgreSQL 服务端会在事务提交时调用操作系统的 fsync() 系统调用,确保数据修改在物理上真实写入磁盘介质。这保障了即便操作系统突发宕机或物理断电,数据库集群依然能够安全恢复到最近一次提交的一致状态。若将其关闭,虽然能够换取极高的写入吞吐,但若发生突发掉电,整个数据库文件极可能完全物理损坏而无法恢复。该参数只能在 postgresql.conf 配置文件中或在服务器命令行中设置。
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 绝不会引入任何数据库物理损坏或不一致风险:操作系统崩溃可能会导致最近提交的少量事务所做的修改丢失,但数据库在重启恢复后的状态与这些事务被干净中止回滚完全相同。因此,当吞吐性能远比绝对的单事务持久性(Durability)更为重要时,关闭 synchronous_commit 是一种极其有价值的高性能选择。深入讨论请参阅 Section 28.4。
若 synchronous_standby_names 非空,synchronous_commit 还会控制事务提交是否等待其 WAL 记录在备用服务器上完成复制处理。
当设置为 remote_apply 时,提交将等待来自当前同步备库的确认响应,确认它们已经接收并回放应用(apply)了该事务的提交记录,使得该修改在备库的查询中立即可见,并且已持久化写入备库磁盘。由于需要等待 WAL 物理回放,这会导致比其他设置大得多的提交等待延迟。当设置为 on 时,提交会等待来自同步备库的响应,确认它们已接收并成功将提交记录刷入持久化存储介质中。这保证了除非主库与所有同步备库的物理存储介质同时遭遇灾难性损坏,否则已提交事务绝不会丢失。当设置为 remote_write 时,提交等待同步备库确认已将数据写入其操作系统的文件系统缓存中。该设置能够抵御备库 PostgreSQL 实例崩溃,但无法抵御备库整机掉电。设置为 local 则仅等待本地刷盘而不等待网络复制(在使用同步复制架构时通常不采用,但为语义完备性而保留提供)。
该参数可在任何时刻动态更改;任何单笔事务的行为由其提交时实际生效的配置值决定。因此,在同一系统中让某些低价值事务异步提交而关键核心事务同步提交是非常实用且普遍的最佳实践。例如,在全局默认为同步提交的系统中,若要让单笔复杂批处理事务异步提交,只需在该事务内部执行 SET LOCAL synchronous_commit TO OFF 即可。
Table 19.1 汇总了 synchronous_commit 各配置项的特性与保障级别。
Table 19.1. synchronous_commit 提交模式对照表
| synchronous_commit 设置 | 本地持久提交 | PostgreSQL 崩溃后备机持久提交 | 操作系统崩溃后备机持久提交 | 备用查询一致性 |
|---|---|---|---|---|
| remote_apply | • | • | • | • |
| on | • | • | • | |
| remote_write | • | • | ||
| local | • | |||
| off |
wal_sync_method (enum)
#
用于强制将 WAL 日志更新刷入物理磁盘的系统调用方法。若 fsync 处于关闭状态,该设置将被自动忽略,因为此时系统完全不会强制刷盘。可选值包括:
open_datasync(使用带有 O_DSYNC 选项的 open() 系统调用写入 WAL 文件)
fdatasync(在每次事务提交时调用 fdatasync())
fsync(在每次事务提交时调用 fsync())
fsync_writethrough(在每次事务提交时调用 fsync(),强制穿透刷透所有磁盘写入缓存)
open_sync(使用带有 O_SYNC 选项的 open() 写入 WAL 文件)
并非所有平台都支持全部这些选项。各平台的默认值是上述列表中首个受该操作系统支持的方法,唯一的例外是在 Linux 和 FreeBSD 上默认值为 fdatasync。默认值不一定在所有存储硬件上都是最优解;可能需要结合具体底层存储环境微调此设置以兼顾奔溃安全性与极致 I/O 性能。相关技术讨论请参阅 Section 28.1。该参数只能在 postgresql.conf 配置文件中或在服务器命令行中设置。
full_page_writes (boolean)
#当此参数开启时,PostgreSQL 服务端在检查点之后首次修改某个数据页时,会将该数据页的完整内容(整页映像 Full Page Image)写入 WAL。这是必不可少的,因为在操作系统突然崩溃时,正在进行的磁盘页写入操作可能只完成了一部分(撕裂页 Partial/Torn Page Write),导致磁盘上的数据页混合了新旧损坏数据。在崩溃恢复期间,通常记录在 WAL 中的行级逻辑变更不足以修复这种损坏页面。写入全页映像可确保数据页能被 100% 正确恢复,代价是增加了写入 WAL 的数据总量。(由于 WAL 回放始终从上一个检查点开始,因此仅需在每个检查点后对每个数据页的首次修改执行全页写入。因此,降低全页写入开销的一种有效途径是适当调大检查点时间间隔参数)。
关闭该参数可加快日常写入性能,但在系统发生掉电或宕机后可能引发不可恢复的物理损坏或静默数据损坏。其风险与关闭 fsync 类似,仅在同类极端测试场景下才建议关闭。
关闭此参数不影响用于时间点恢复(PITR)的 WAL 连续归档功能(参见 Section 25.3)。
该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。默认值为 on。
wal_log_hints (boolean)
#
当该参数为 on 时,PostgreSQL 服务端在检查点后首次修改数据页时,即使是对于所谓“提示位”(Hint Bits)的非关键修改,也会将整页映像写入 WAL。
如果启用了数据页校验和(Data Checksums),提示位更新始终会记录到 WAL 中,此时该设置会被自动忽略。可以使用此设置来测试如果数据库启用了校验和会额外产生多少 WAL 日志。
该参数只能在服务器启动时设置。默认值为 off。
wal_compression (enum)
#
该参数启用使用指定压缩算法对 WAL 日志进行压缩。启用后,PostgreSQL 服务端会对写入 WAL 的全页映像(FPI)进行高效压缩(例如当 full_page_writes 开启时、在基础备份期间等)。压缩的页面映像将在 WAL 回放期间自动解压缩。支持的算法包括 pglz、lz4(若编译时支持 --with-lz4)以及 zstd(若编译时支持 --with-zstd)。值 on 是 pglz 的历史同义写法。默认值为 off。仅超级用户或具有特定权限的角色可以更改此设置。
开启压缩可以在不增加任何数据损坏风险的前提下显著降低 WAL 日志体积并减小 I/O 写入带宽,代价是在 WAL 写入时消耗适度的 CPU 压缩开销以及在回放时消耗解压开销(lz4 与 zstd 表现极其优异)。
wal_init_zero (boolean)
#
若设置为 on(默认值),此选项会使新创建的 WAL 段文件预先填充全零。在某些文件系统上,这能确保在实际写入 WAL 记录之前预先分配连续的物理存储空间。然而,写时复制(COW,如 Btrfs、ZFS)文件系统可能无法从此预分配中受益,因此提供该选项以跳过不必要的零填充开销。若设置为 off,在创建文件时仅写入最后一个字节以使其具有预期的大小时长。
wal_recycle (boolean)
#
若设置为 on(默认值),该选项使过期的旧 WAL 文件在检查点时通过重命名直接循环复用,避免频繁创建和删除文件带来的元数据锁竞争。在 COW 文件系统上,直接创建新文件可能更快,因此提供了禁用此回收行为的选项。
wal_buffers (integer)
#
用于存放尚未刷盘的 WAL 数据的共享内存缓冲区大小。默认设置 -1 会自动选择相当于 shared_buffers 的 1/32(约 3%),且不少于 64kB,不大于单个 WAL 段文件的物理大小(通常为 16MB)。若自动计算值偏大或偏小可手动配置,但任何小于 32kB 的正值都会被自动向上取整为 32kB。该参数只能在服务器启动时设置。
WAL 缓冲区的内容在每次事务提交时都会刷盘,因此设置极端过大的数值很难带来额外收益。然而,在高并发写入的繁忙生产服务器上,将此数值设置为至少数兆字节(如默认自动计算的 16MB)可以大幅改善突发并发提交时的吞吐表现。默认设置 -1 的自适应调优在绝大多数场景下均表现优异。
wal_writer_delay (integer)
#
指定 WAL 写入器后台进程刷盘的时间间隔周期。在完成一轮刷盘后,WAL 写入器会休眠 wal_writer_delay 时长,除非被异步提交事务提前唤醒。若距离上次刷盘的时间小于该延迟且新产生的 WAL 量小于 wal_writer_flush_after,则 WAL 仅写入操作系统缓存而不强制同步刷盘。若不带单位,按毫秒计算。默认值为 200 毫秒(200ms)。该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。
wal_writer_flush_after (integer)
#
指定 WAL 写入器按日志体量触发刷盘的阈值。若距离上次刷盘小于延迟时间且增量 WAL 小于该值,则仅写入文件系统。若设置为 0,则每次均立刻同步刷盘。默认值为 1MB。该参数只能在配置文件中或命令行中设置。
wal_skip_threshold (integer)
#
当 wal_level 为 minimal 且事务在创建或重写永久关系后提交时,该设置决定如何持久化新写入的数据。若数据量小于该阈值,将其写入 WAL 日志;否则对受影响的文件直接执行 fsync。默认值为 2MB(2MB)。
commit_delay (integer)
#
设置 commit_delay 会在发起 WAL 刷盘之前增加一个短暂的时间延迟。在高并发场景下,这能够让更多准备就绪的事务合并到单次物理刷盘中完成组提交(Group Commit),从而大幅提高系统整体提交吞吐量。然而,这也会使单笔事务的提交延迟增加至多 commit_delay。若在准备发起刷盘时活跃并发事务数少于 commit_siblings,或者关闭了 fsync,则不执行任何延迟。若不带单位按微秒计算。默认值为 0(无延迟)。
在 9.3 之前的版本中该参数机制效率较低。自 PostgreSQL 9.3 起,首个准备刷盘的进程等待配置的延迟时间,而后续进程仅需等待领头进程(Leader)完成刷盘操作即可直接返回。
commit_siblings (integer)
#
在执行 commit_delay 延迟之前所要求必须处于活跃状态的最小并发打开事务数。较大的数值能进一步确保在延迟窗口内至少有其他事务准备就绪以便组提交。默认值为 5 个事务。
checkpoint_timeout (integer)
#
两次常规自动物理检查点(Checkpoint)之间的最大允许时间间隔。若指定该值时不带单位,则按秒计算。合法取值范围在 30 秒至 1 天之间。默认值为 5 分钟(5min)。调大该参数可以平滑 I/O 峰值,但会增加系统发生断电故障恢复时所需的回放时间。该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。
checkpoint_completion_target (floating point)
#
指定检查点完成的目标时间,表示为检查点之间总间隔时长的比例系数。默认值为 0.9,这会将脏页刷盘的 I/O 平滑分摊到两次检查点之间 90% 的时间窗口中,从而提供极其平稳均衡的物理 I/O 负载,同时也为检查点收尾工作留出充裕的缓冲时间。不建议调小该参数,因为那会导致脏页在极短时间内集中刷盘引发 I/O 尖刺风暴。该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。
checkpoint_flush_after (integer)
#
在执行检查点期间,每当写入超过此数量的数据后,尝试强制操作系统内核将这些写入下发至物理存储介质(Writeback)。这能够有效控制内核 Page Cache 中的脏页总量,从而消除在检查点末尾集中执行 fsync 时引发的 I/O 卡顿停顿。在 Linux 上的默认值为 256kB,在其他平台上默认为 0。该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。
checkpoint_warning (integer)
#
如果由于 WAL 日志段文件快速填满而触发检查点的时间间隔短于该阈值,则向服务端日志打印一条警告信息(这强烈暗示应当适当调大 max_wal_size)。若不带单位按秒计算。默认值为 30 秒(30s)。设置为 0 将禁用该警告。该参数只能在配置文件中或命令行中设置。
max_wal_size (integer)
#
在自动检查点周期之间允许 WAL 日志文件膨胀增长的最大物理尺寸上限。这是一个软限制。默认值为 1 GB。在生产环境高写入吞吐场景下,通常将其调大至 16GB 到 64GB 以上以平滑 I/O 尖刺。调大该参数会增加系统崩溃恢复所需的时间。该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。
min_wal_size (integer)
#
只要 WAL 磁盘使用量低于该设置值,在检查点发生时旧 WAL 文件始终会被循环重命名复用,而非直接从文件系统中删除。这可用于预留充足的 WAL 磁盘空间以应对大批量作业执行时的突发写入洪峰。默认值为 80MB。该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。
archive_mode (enum)
#
当启用 archive_mode 时,写满的 WAL 日志段文件会通过配置 archive_command 或 archive_library 发送到归档存储库。除用于禁用的 off 外,还支持两种模式:on 和 always。在常规正常运行期间,这两种模式没有差异;但当设置为 always 时,WAL 归档器在归档恢复或备库只读模式期间同样处于激活状态。在 always 模式下,从归档恢复或通过流复制接收的所有 WAL 文件都会再次被归档(二次归档)。详见 Section 26.2.9。
archive_mode 独立于 archive_command 和 archive_library 单独设置,这样可以在无需退出归档模式的情况下动态更换具体的归档命令或归档扩展库。该参数只能在服务器启动时设置。当 wal_level 设置为 minimal 时无法启用归档模式。
archive_command (string)
#
用于归档已完成 WAL 段文件的本地 Shell 命令。字符串中的任何 %p 会被替换为要归档文件的物理路径,而任何 %f 仅被替换为文件名本身(该路径是相对于服务端工作目录,即集群数据目录的相对路径)。若要在命令中嵌入字面量 % 字符,请书写为 %%。非常关键的一点是:该命令仅在归档操作真正成功时才返回退出码 0。更多信息请参阅 Section 25.3.1。
该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。仅当服务器在启动时启用了 archive_mode 且 archive_library 为空字符串时才会使用该参数。若同时设置了 archive_command 和 archive_library,系统将抛出错误。若在启用归档模式时 archive_command 仍为空字符串,WAL 归档会被临时挂起,但服务器会持续积攒 WAL 文件并阻止回收,期望管理员尽快提供命令。将该参数设置为无操作仅返回 true 的命令(例如 /bin/true)实际上禁用了归档,但会破坏归档链条,仅限在特殊紧急场景下采用。
archive_library (string)
#用于归档已完成 WAL 段文件的动态共享库模块。若设置为空字符串(默认值),则启用传统的 Shell 归档方式并使用 archive_command。若同时配置了二者,系统将报错。否则,将使用指定的动态链接库执行归档。当此参数修改时,主进程会自动重启 WAL 归档器进程。详见 Section 25.3.1 和 Chapter 49。
这个参数只能在
postgresql.conf 文件中或服务器命令行上设置。
archive_timeout (integer)
#
archive_command 或 archive_library 仅针对已写满的 16MB WAL 段文件触发调用。因此,如果您的服务器写入量较低(或处于业务低谷期),在事务完成提交与其实际被安全转存到归档存储之间可能会存在较长时间的延迟。为了限制未归档数据的最长时限,可以配置 archive_timeout 强制服务器定期切换到新的 WAL 段文件。当此参数大于 0 时,只要自上次切换以来超过该时间间隔且系统存在任何数据库活动(包括检查点),服务器就会强制切换到新段文件。请注意,因强制切换而提前归档的文件在物理上依然具有与完整段文件相同的 16MB 长度。因此设置极短的 archive_timeout 是不明智的,这会导致归档存储膨胀。通常设置为数分钟是合理的。若需要更低延迟的数据异地同步,应优先采用流复制。若不带单位按秒计算。
本节介绍通用于各类恢复过程的通用配置参数,影响系统崩溃恢复、流复制以及基于归档的重放复制。
recovery_prefetch (enum)
#
在恢复回放期间,是否尝试预取(Prefetch)WAL 中引用但尚未加载到共享缓冲池中的磁盘数据块。合法取值为 off、on 以及 try(默认值)。设置 try 仅在宿主操作系统支持预读建议系统调用(如 posix_fadvise)时才启用预取。
预取后续即将被回放引用的数据块能够在特定工作负载下大幅减少恢复期间的 I/O 等待时间。另请参阅 wal_decode_buffer_size 和 maintenance_io_concurrency,它们限制了并发预取的深度。
wal_decode_buffer_size (integer)
#设置服务器为了寻找可预取的数据块而在 WAL 日志流中向前预读的最大边界。若不带单位按字节计算。默认值为 512kB。该参数只能在服务器启动时设置。
本节介绍仅在恢复持续期间生效的专属配置参数。在未来需要执行的后续任何恢复流程中,必须重新配置这些参数。
“恢复”(Recovery)涵盖将服务器作为备库运行,或者执行定向数据恢复。通常,备库只读模式用于提供高可用性以及读扩展能力,而定向恢复主要用于从意外数据丢失中挽回数据。
要以备库模式启动服务器,请在数据目录中创建一个名为 standby.signal 的触发标识文件。服务器将进入恢复流程,并且在读取到已归档 WAL 的末尾时绝不终止恢复,而是通过连接到由 primary_conninfo 指定的主库或使用 restore_command 获取增量 WAL 段文件来持续不断地回放恢复。针对此模式,本节及 Section 19.6.3 中的参数最为关键。
要以定向恢复模式启动服务器,请在数据目录中创建名为 recovery.signal 的文件。如果同时创建了这两个信号文件,备库模式优先。定向恢复模式会在已归档的 WAL 全部回放完毕或到达配置的 recovery_target 时正常终止恢复并升级为主库。
restore_command (string)
#
用于从归档存储中检索获取已归档 WAL 段文件的本地 Shell 命令。该参数对于归档恢复是必选的,而对于纯流复制则是可选的。字符串中的任何 %f 会被替换为要从归档库拉取的段文件名,而 %p 会被替换为服务器本地的目标复制路径。任何 %r 会被替换为包含最近有效重启点的文件名(这是保持恢复可重启所需保留的最早文件)。若要表示字面量百分号请书写为 %%。
极为关键的是:该命令仅在成功拉取文件时才返回退出码 0。系统必然会尝试向该命令请求归档库中尚未生成的最新段文件;当被请求不存在的文件时,该命令必须返回非零退出码。示例如下:
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy "C:\server\archivedir\%f" "%p"' # Windows
例外情况是:如果命令被异常信号杀死或被 Shell 报错(如找不到命令),则恢复将直接中止且服务器拒绝启动。
这个参数只能在 postgresql.conf
文件中或服务器命令行上设置。
archive_cleanup_command (string)
#
该可选参数指定在每次重启点(restartpoint)处触发执行的 Shell 清理命令。archive_cleanup_command 旨在提供一种自动清理备用服务器不再需要的陈旧归档 WAL 文件的机制。其中的 %r 会被替换为包含最近有效重启点的文件名(早于 %r 的所有文件均可安全删除)。随附的 pg_archivecleanup 模块常用于配合该命令:
archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
请注意:若有多台备库共享读取同一个归档目录,需确保在所有备库均已完成回放之前不要过早删除文件。若要书写字面量 % 请书写为 %%。
若清理命令返回非零退出码,系统将记录一条 WARNING 警告日志。但若命令被异常信号终止或由 Shell 报错,系统将引发 FATAL 致命错误。
这个参数只能在 postgresql.conf
文件中或服务器命令行上设置。
recovery_end_command (string)
#
该参数指定在整个恢复流程彻底结束时仅执行一次的 Shell 命令。该参数是可选的,用于提供在恢复完成后进行清理或发送通知的机制。其中的 %r 与 archive_cleanup_command 一样被替换为最后有效重启点文件名。
若该命令返回非零退出码,系统会记录一条警告日志,但数据库仍会继续正常启动。例外的是如果命令被异常信号终止或遭遇 Shell 执行故障,数据库将拒绝继续启动。
这个参数只能在 postgresql.conf
文件中或服务器命令行上设置。
默认情况下,恢复会进行到 WAL 日志的末尾。以下参数可用于指定一个
更早的停止点。
recovery_target、
recovery_target_lsn、
recovery_target_name、
recovery_target_time 和
recovery_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 25.3.5。
recovery_target_action (enum)
#
指定一旦到达恢复目标,服务器应当采取什么动作。默认值为
pause,表示恢复将被暂停。
promote
表示恢复过程将结束,服务器将开始接受连接。
最后,shutdown
将在到达恢复目标之后停止服务器。
pause
设置的预期用途是允许对数据库执行查询,以检查这个恢复目标是否
是最理想的恢复点。暂停状态可以通过
pg_wal_replay_resume()
(参见 Table 9.99)
恢复,随后恢复将结束。如果这个恢复目标不是所期望的停止点,
则关闭服务器,把恢复目标设置改为更晚的目标并重启,
以继续恢复。
shutdown
设置的用途是让实例准备好停在你想要的精确重放点上。
实例仍然能够重放更多的 WAL 记录(实际上,它下次启动时将必须
重放自上一个检查点以来的 WAL 记录)。
注意,由于当 recovery_target_action
被设置为 shutdown 时
recovery.signal
不会被移除,除非更改配置或手动删除
recovery.signal 文件,
否则任何后续的启动都将以立即关闭告终。
如果没有设置恢复目标,这个设置没有任何效果。
如果未启用 hot_standby,
那么 pause 设置的行为与
shutdown 相同。
如果在提升正在进行时到达恢复目标,
pause 设置的行为与
promote 相同。
无论如何,如果配置了恢复目标但归档恢复在到达目标之前结束, 服务器将因致命错误而关闭。
这些设置控制 WAL 汇总,这是一项必须启用才能执行 增量备份 的功能。
summarize_wal (boolean)
#
启用 WAL 汇总进程。注意,WAL 汇总既可以在主服务器上启用,
也可以在备用服务器上启用。这个参数只能在
postgresql.conf 文件中或服务器命令行上
设置。默认值为 off。
如果 wal_level
被设置为 minimal,服务器将无法以
summarize_wal=on
启动。如果在服务器启动之后、在 wal_level=minimal
的情况下配置了 summarize_wal=on,
汇总进程会运行,但拒绝为任何以
wal_level=minimal 生成的 WAL
生成汇总文件。
wal_summary_keep_time (integer)
#
配置 WAL 汇总进程自动移除旧 WAL 汇总之前所经过的时间。
文件时间戳用于判断哪些文件已经旧到可以移除。通常,你应当把它
设置得明显高于一次备份与依赖于它的后续增量备份之间可能经过的
时间。从前一次备份到正在执行的新备份之间的整个 WAL
记录范围都必须有可用的 WAL 汇总;否则,增量备份将失败。
如果这个参数被设置为零,WAL 汇总将不会被自动删除,但手动删除
你确信未来的增量备份不需要的文件是安全的。
这个参数只能在
postgresql.conf 文件中或服务器命令行上
设置。
如果这个值没有指定单位,则以分钟为单位。
默认值为 10 天。如果 summarize_wal = off,
那么无论这个参数取值如何,现有的 WAL 汇总都不会被移除,
因为 WAL 汇总进程不会运行。