有关调整这些设置的更多信息,请参阅第 28.5 节。
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
并且执行了许多 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
可以成为当性能比事务持久性的精确确定性更重要时的有用替代方案。更多讨论请参阅第 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 崩溃后备用持久提交 | 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 文件)
并非所有这些选择在所有平台上都可用。默认值是列表中第一个平台支持的方法,但 fdatasync
是 Linux 和 FreeBSD 上的默认值。默认值不一定是最优的;可能需要更改此设置或系统配置的其他方面才能创建崩溃安全配置或实现最佳性能。这些方面在第 28.1 节中进行了讨论。此参数只能在 postgresql.conf
文件或服务器命令行中设置。
full_page_writes
(boolean
) #当此参数开启时,PostgreSQL 服务器在检查点后首次修改页面时,会将每个磁盘页面的全部内容写入 WAL。这是必需的,因为在操作系统崩溃期间正在进行的页面写入可能只部分完成,导致磁盘上的页面包含新旧数据混合。通常存储在 WAL 中的行级更改数据不足以在崩溃后恢复中完全恢复 such a page。存储完整的页面映像可以保证页面可以被正确恢复,但代价是增加了必须写入 WAL 的数据量。(由于 WAL 重放总是从检查点开始,因此在检查点后对每个页面的首次更改时执行此操作就足够了。因此,减少全页写入成本的一种方法是增加检查点间隔参数。)
关闭此参数可以加快正常操作速度,但在系统故障后可能导致无法恢复的数据损坏或数据静默损坏。风险与关闭 fsync
类似,尽管风险较小,并且只有在建议用于该参数的相同情况下才能关闭它。
关闭此参数不会影响使用 WAL 归档进行时间点恢复(PITR)(参见第 25.3 节)。
此参数只能在 postgresql.conf
文件或服务器命令行中设置。默认值为 on
。
wal_log_hints
(boolean
) #当此参数为 on
时,PostgreSQL 服务器在检查点后首次修改页面时,会将每个磁盘页面的全部内容写入 WAL,即使是对所谓的提示位(hint bits)进行非关键修改也是如此。
如果启用了数据校验和,则提示位更新始终会写入 WAL,并且此设置将被忽略。您可以使用此设置来测试如果数据库启用了数据校验和,会产生多少额外的 WAL 日志记录。
此参数只能在服务器启动时设置。默认值为 off
。
wal_compression
(enum
) #此参数启用使用指定压缩方法的 WAL 压缩。启用后,PostgreSQL 服务器会压缩写入 WAL 的全页映像(例如,当 full_page_writes 开启时、在基准备份期间等)。压缩后的页面映像将在 WAL 重放期间解压缩。支持的方法包括 pglz
、lz4
(如果 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_level
为 minimal
并且事务在创建或重写永久关系后提交时,此设置决定了如何持久化新数据。如果数据小于此设置,则将其写入 WAL 日志;否则,使用对受影响文件的 fsync。根据您的存储属性,提高或降低此值可能会在提交减慢并发事务时有所帮助。如果指定此值时不带单位,则将其视为千字节。默认值为两兆字节(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
延迟之前所需的并发打开事务的最小数量。较大的值会使在延迟间隔内至少有另一个事务准备好提交的可能性更大。默认值为五个事务。
checkpoint_timeout
(integer
) #自动 WAL 检查点之间的最大时间。如果指定此值时不带单位,则将其视为秒。有效范围在 30 秒到 1 天之间。默认值为五分钟(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 但小于 OS 的页面缓存时,性能可能会下降。此设置在某些平台上可能无效。如果指定此值时不带单位,则将其视为块,即 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_command
或 archive_library
失败,或 wal_keep_size
设置过高时,WAL 大小可能会超过 max_wal_size
。如果指定此值时不带单位,则将其视为兆字节。默认值为 1 GB。增加此参数可能会增加崩溃恢复所需的时间。此参数只能在 postgresql.conf
文件或服务器命令行中设置。
min_wal_size
(integer
) #只要 WAL 磁盘使用量保持在此设置以下,旧 WAL 文件将在检查点时始终被循环使用,而不是被删除。这可以确保为应对 WAL 使用量的峰值(例如,在运行大型批处理作业时)保留足够的 WAL 空间。如果指定此值时不带单位,则将其视为兆字节。默认值为 80 MB。此参数只能在 postgresql.conf
文件或服务器命令行中设置。
archive_mode
(enum
) #当 archive_mode
启用时,通过设置 archive_command 或 archive_library 将已完成的 WAL 段发送到归档存储。除了 off
(禁用)之外,还有两种模式:on
和 always
。在正常操作期间,这两种模式之间没有区别,但设置为 always
时,WAL 归档器在归档恢复或备用模式下也启用。在 always
模式下,从归档中恢复的所有文件或使用流复制流式传输的所有文件将被(再次)归档。详情请参阅第 26.2.9 节。
archive_mode
是一个独立于 archive_command
和 archive_library
的设置,以便 archive_command
和 archive_library
可以在不离开归档模式的情况下进行更改。此参数只能在服务器启动时设置。archive_mode
在 wal_level
设置为 minimal
时无法启用。
archive_command
(string
) #用于归档已完成的 WAL 文件段的本地 shell 命令。字符串中的任何 %p
都将被替换为要归档的文件路径名,任何 %f
都将被替换为仅文件名。(路径名相对于服务器的工作目录,即集群的数据目录。)使用 %%
在命令中嵌入实际的 %
字符。重要的是命令仅在成功时才返回零退出状态。有关更多信息,请参阅第 25.3.1 节。
此参数只能在 postgresql.conf
文件或服务器命令行中设置。仅当 archive_mode
在服务器启动时启用且 archive_library
设置为空字符串时才使用。如果同时设置了 archive_command
和 archive_library
,则会引发错误。如果 archive_command
为空字符串(默认),而 archive_mode
已启用(且 archive_library
设置为空字符串),则 WAL 归档将被临时禁用,但服务器将继续累积 WAL 段文件,以期望很快会提供命令。将 archive_command
设置为一个什么都不做但返回 true 的命令,例如 /bin/true
(Windows 上为 REM
),实际上会禁用归档,但也会破坏归档恢复所需的 WAL 文件链,因此它只应在特殊情况下使用。
archive_library
(string
) #用于归档已完成的 WAL 文件段的库。如果设置为字符串(默认),则启用通过 shell 的归档,并使用 archive_command。如果同时设置了 archive_command
和 archive_library
,则会引发错误。否则,将使用指定的共享库进行归档。WAL 归档进程由 postmaster 在此参数更改时重新启动。有关更多信息,请参阅第 25.3.1 节和第 49 章。
此参数只能在 postgresql.conf
文件或服务器命令行中设置。
archive_timeout
(integer
) #仅为已完成的 WAL 段调用 archive_command 或 archive_library。因此,如果您的服务器生成的 WAL 流量很少(或有间歇性流量),则从事务完成到其安全记录在归档存储中可能需要很长时间。为了限制未归档数据的年龄,您可以设置 archive_timeout
以定期强制服务器切换到新的 WAL 段文件。当此参数大于零时,服务器将在自上次段文件切换以来经过此时间量并且有任何数据库活动后切换到新段文件,包括单个检查点(如果没有数据库活动,则跳过检查点)。请注意,由于强制切换而提前关闭的归档文件仍具有与完全满的文件相同的长度。因此,使用非常短的 archive_timeout
是不明智的——它会使您的归档存储膨胀。通常,一分钟左右的 archive_timeout
设置是合理的。如果您希望数据比这更快地从主服务器复制,您应该考虑使用流复制而不是归档。如果指定此值时不带单位,则将其视为秒。此参数只能在 postgresql.conf
文件或服务器命令行中设置。
本节描述了适用于一般恢复的设置,影响崩溃恢复、流复制和基于归档的复制。
recovery_prefetch
(enum
) #在恢复期间,是否尝试预取 WAL 中引用的但尚未在缓冲区池中的块。有效值为 off
、on
和 try
(默认)。try
设置仅在操作系统支持发出预读建议时才启用预取。
预取即将需要的块可以减少某些工作负载下的恢复期间的 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 段来继续恢复。对于此模式,本节和第 19.6.3 节中的参数很重要。第 19.5.6 节中的参数也将被应用,但通常在此模式下无用。
要将服务器置于目标性恢复模式,请在数据目录中创建一个名为 recovery.signal
的文件。如果同时创建了 standby.signal
和 recovery.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
的文件都可以安全地删除。这些信息可用于将归档截断到仅支持从当前恢复进行重启所需的最少内容。对于单备用配置,通常在 archive_cleanup_command
中使用 pg_archivecleanup 模块,例如
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
文件或服务器命令行中设置。
默认情况下,恢复将恢复到 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
) #此参数指定恢复将进行到的写入预日志(write-ahead log)位置的 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)。
通常,您只需要在复杂的多重恢复场景中设置此参数,您需要返回到自身已通过时间点恢复达到的状态。有关讨论,请参阅第 25.3.6 节。
recovery_target_action
(enum
) #指定服务器一旦达到恢复目标应采取的操作。默认值为 pause
,表示恢复将暂停。promote
表示恢复过程将完成,服务器将开始接受连接。最后,shutdown
将在达到恢复目标后停止服务器。
设置 pause
的目的是允许对数据库执行查询,以检查此恢复目标是否是最理想的恢复点。可以通过使用 pg_wal_replay_resume()
(参见表 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
启动服务器。如果在服务器启动后配置了 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 汇总器将不会运行。
如果您在文档中看到任何不正确、与特定功能的使用体验不符或需要进一步澄清的内容,请使用此表格报告文档问题。