有关调整这些设置的更多信息,请参见第 28.5 节。
wal_level
(枚举
) #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
(布尔型
) #如果此参数打开,则 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
(枚举
) #指定在数据库服务器向客户端返回“成功”指示之前必须完成多少 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 崩溃后备库持久化提交 | 操作系统崩溃后备库持久化提交 | 备库查询一致性 |
---|---|---|---|---|
远程应用 | • | • | • | • |
开启 | • | • | • | |
远程写入 | • | • | ||
本地 | • | |||
关闭 |
wal_sync_method
(枚举
) #用于强制将 WAL 更新写入磁盘的方法。如果 fsync
关闭,则此设置无关紧要,因为 WAL 文件更新根本不会被强制写入。可能的值为
open_datasync
(使用 open()
选项 O_DSYNC
写入 WAL 文件)
fdatasync
(在每次提交时调用 fdatasync()
)
fsync
(在每次提交时调用 fsync()
)
fsync_writethrough
(在每次提交时调用 fsync()
,强制写入任何磁盘写入缓存)
open_sync
(使用 open()
选项 O_SYNC
写入 WAL 文件)
并非所有这些选项在所有平台上都可用。默认情况下是上述列表中平台支持的第一个方法,但 Linux 和 FreeBSD 上的默认值为 fdatasync
。默认值不一定是最理想的;可能需要更改此设置或系统配置的其他方面才能创建防崩溃配置或获得最佳性能。这些方面在第 28.1 节中讨论。此参数只能在 postgresql.conf
文件或服务器命令行中设置。
full_page_writes
(布尔型
) #当此参数开启时,PostgreSQL 服务器会在检查点后对每个磁盘页面的第一次修改期间将整个页面内容写入 WAL。这是因为在操作系统崩溃期间正在进行的页面写入可能只完成了一部分,从而导致磁盘上的页面包含旧数据和新数据的混合。通常存储在 WAL 中的行级更改数据不足以在崩溃后恢复期间完全恢复此类页面。存储完整的页面映像可确保页面能够正确恢复,但代价是增加了必须写入 WAL 的数据量。(因为 WAL 重放总是从检查点开始,所以在检查点后每个页面的第一次更改期间执行此操作就足够了。因此,减少全页写入成本的一种方法是增加检查点间隔参数。)
关闭此参数可以加快正常操作速度,但可能会导致系统故障后出现不可恢复的数据损坏或静默数据损坏。风险类似于关闭 fsync
,尽管较小,并且仅应在建议关闭该参数的相同情况下关闭它。
关闭此参数不会影响使用 WAL 归档进行时间点恢复 (PITR)(参见第 25.3 节)。
此参数只能在 postgresql.conf
文件或服务器命令行中设置。默认值为 开启
。
wal_log_hints
(布尔型
) #当此参数为 开启
时,PostgreSQL 服务器会在检查点后对每个磁盘页面的第一次修改期间将整个页面内容写入 WAL,即使是对所谓的提示位的非关键修改也是如此。
如果启用了数据校验和,则提示位更新始终会被记录到 WAL 中,并且会忽略此设置。您可以使用此设置来测试如果您的数据库启用了数据校验和,则会发生多少额外的 WAL 记录。
此参数只能在服务器启动时设置。默认值为 关闭
。
wal_compression
(枚举
) #此参数使用指定的压缩方法启用 WAL 压缩。启用后,PostgreSQL 服务器会在 full_page_writes 开启或基本备份期间压缩写入 WAL 的完整页面映像。压缩的页面映像将在 WAL 重放期间解压缩。支持的方法为 pglz
、lz4
(如果 PostgreSQL 使用 --with-lz4
编译)和 zstd
(如果 PostgreSQL 使用 --with-zstd
编译)。默认值为 关闭
。只有超级用户和具有相应 SET
权限的用户可以更改此设置。
启用压缩可以减少 WAL 量,而不会增加不可恢复的数据损坏的风险,但代价是在 WAL 记录期间压缩会消耗一些额外的 CPU,在 WAL 重放期间解压缩也会消耗一些额外的 CPU。
wal_init_zero
(布尔型
) #如果设置为 开启
(默认值),则此选项会导致新的 WAL 文件用零填充。在某些文件系统上,这确保了在需要写入 WAL 记录之前分配空间。但是,写时复制 (COW) 文件系统可能无法从此技术中获益,因此提供了跳过不必要工作的选项。如果设置为 关闭
,则在创建文件时仅写入最后一个字节,以便文件具有预期的尺寸。
wal_recycle
(布尔型
) #如果设置为 开启
(默认值),则此选项会导致 WAL 文件通过重命名进行回收,避免需要创建新文件。在 COW 文件系统上,创建新文件可能更快,因此提供了禁用此行为的选项。
wal_buffers
(整数
) #用于尚未写入磁盘的 WAL 数据的共享内存量。-1 的默认设置选择的大小等于 shared_buffers 的 1/32(约 3%),但不少于 64kB
,也不超过一个 WAL 段的大小,通常为 16MB
。如果自动选择的大小太大或太小,可以手动设置此值,但任何小于 32kB
的正值都将被视为 32kB
。如果指定此值时没有单位,则将其视为 WAL 块,即 XLOG_BLCKSZ
字节,通常为 8kB。此参数只能在服务器启动时设置。
WAL 缓冲区的内容在每次事务提交时都会写入磁盘,因此极大的值不太可能带来明显的优势。但是,将此值设置为至少几兆字节可以提高繁忙服务器上的写入性能,在繁忙服务器上,许多客户端同时提交。在大多数情况下,默认设置 -1 选择的自动调整应提供合理的结果。
wal_writer_delay
(整数
) #指定 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
(整数
) #指定 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
(整数
) #当 wal_level
为 minimal
并且事务在创建或重写永久关系后提交时,此设置决定如何持久化新数据。如果数据小于此设置,则将其写入 WAL 日志;否则,使用受影响文件的 fsync。根据存储的属性,如果此类提交正在减慢并发事务的速度,则提高或降低此值可能会有所帮助。如果指定此值时没有单位,则将其视为千字节。默认值为 2 兆字节 (2MB
)。
commit_delay
(整数
) #设置 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
(整数
) #在执行commit_delay
延迟之前需要达到的并发打开事务的最小数量。较大的值会使至少一个其他事务在延迟间隔内准备好提交的可能性更高。默认值为五个事务。
checkpoint_timeout
(integer
) #自动WAL检查点之间允许的最大时间。如果此值未指定单位,则默认为秒。有效范围为30秒到一天。默认值为五分钟(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。有效范围为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增长的最大大小。这是一个软限制;在特殊情况下,WAL大小可能会超过max_wal_size
,例如重负载、archive_command
或archive_library
故障或wal_keep_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
,则会引发错误。否则,将使用指定的共享库进行归档。当此参数更改时,postmaster会重新启动WAL归档程序进程。有关更多信息,请参阅第 25.3.1 节和第 49 章。
此参数只能在postgresql.conf
文件中或服务器命令行上设置。
archive_timeout
(integer
) #archive_command或archive_library仅对已完成的WAL段调用。因此,如果您的服务器生成很少的WAL流量(或有空闲时间段),则在事务完成与其在归档存储中安全记录之间可能会有很长的延迟。为了限制未归档数据的旧程度,您可以设置archive_timeout
以强制服务器定期切换到新的WAL段文件。当此参数大于零时,服务器将在此时间量过去且存在任何数据库活动(包括单个检查点)后切换到新的段文件(如果不存在数据库活动,则跳过检查点)。请注意,由于强制切换而过早关闭的归档文件仍然与完全填充的文件具有相同的长度。因此,不建议使用非常短的archive_timeout
——这会使您的归档存储膨胀。archive_timeout
设置为一分钟左右通常是合理的。如果您希望数据复制出主服务器的速度比这更快,则应考虑使用流复制而不是归档。如果此值未指定单位,则默认为秒。此参数只能在postgresql.conf
文件中或服务器命令行上设置。
本节描述适用于一般恢复的设置,影响崩溃恢复、流复制和基于归档的复制。
recovery_prefetch
(enum
) #在恢复期间,是否尝试预取WAL中引用的但尚未在缓冲池中的块。有效值为off
、on
和try
(默认值)。设置try
仅在操作系统提供posix_fadvise
函数时启用预取,该函数目前用于实现预取。请注意,某些操作系统提供了该函数,但它什么也不做。
预取很快就会需要的块可以减少某些工作负载在恢复期间的I/O等待时间。另请参阅wal_decode_buffer_size和maintenance_io_concurrency设置,它们限制预取活动。
wal_decode_buffer_size
(integer
) #限制服务器在WAL中向前查找以查找要预取的块的范围。如果指定此值而不带单位,则将其视为字节。默认值为 512kB。
本节描述仅在恢复期间适用的设置。对于您希望执行的任何后续恢复,必须重置这些设置。
“恢复”涵盖将服务器用作备用服务器或执行目标恢复。通常,备用模式用于提供高可用性和/或读取可扩展性,而目标恢复用于从数据丢失中恢复。
要以备用模式启动服务器,请在数据目录中创建一个名为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
的文件都可以安全删除。此信息可用于将归档截断为仅支持从当前恢复重新启动所需的最小值。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
文件中或服务器命令行上设置。
默认情况下,恢复将恢复到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)。
通常,您只需要在复杂的重新恢复情况下设置此参数,在这些情况下,您需要返回到自身在特定时间点恢复后达到的状态。有关讨论,请参见第 25.3.6 节。
recovery_target_action
(enum
) #指定恢复目标达到后服务器应采取的操作。默认值为pause
,表示恢复将暂停。promote
表示恢复过程将完成,服务器将开始接受连接。最后shutdown
将在达到恢复目标后停止服务器。
使用pause
设置的目的是允许对数据库执行查询,以检查此恢复目标是否为最理想的恢复点。可以使用pg_wal_replay_resume()
恢复暂停状态(参见表 9.97),这将导致恢复结束。如果此恢复目标不是所需的停止点,则关闭服务器,将恢复目标设置更改为稍后的目标并重新启动以继续恢复。
设置shutdown
可用于使实例在所需的精确回放点准备就绪。实例仍然能够回放更多 WAL 记录(实际上,由于下次启动时需要回放自上次检查点以来的 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 摘要程序不会运行。
如果您在文档中看到任何不正确的内容,与您对特定功能的体验不符,或需要进一步澄清,请使用此表单报告文档问题。