连续归档可用于创建具有一个或多个备用服务器的高可用性 (HA) 集群配置，如果主服务器发生故障，这些备用服务器可以接管操作。此功能通常称为温备或日志传输。
主服务器和备用服务器协同工作以提供此功能，尽管服务器之间仅松散耦合。主服务器在连续归档模式下运行，而每个备用服务器在连续恢复模式下运行，从主服务器读取 WAL 文件。启用此功能不需要对数据库表进行任何更改，因此与某些其他复制解决方案相比，它提供了较低的管理开销。此配置对主服务器的性能影响也相对较低。
将 WAL 记录直接从一个数据库服务器移动到另一个数据库服务器通常称为日志传输。PostgreSQL 通过一次传输一个文件（WAL 段）来实现基于文件的日志传输。WAL 文件 (16MB) 可以轻松且廉价地传输到任何距离，无论是相邻系统、同一站点上的其他系统，还是全球另一端的系统。此技术所需的带宽根据主服务器的事务速率而变化。基于记录的日志传输更细粒度，并且通过网络连接增量地传输 WAL 更改（请参阅第 26.2.5 节）。
需要注意的是，日志传输是异步的，即 WAL 记录在事务提交后才传输。因此，如果主服务器发生灾难性故障，则存在数据丢失的窗口；尚未传输的事务将丢失。基于文件的日志传输中数据丢失窗口的大小可以通过使用archive_timeout参数来限制，该参数可以设置为几秒。但是，如此低的设置会大大增加文件传输所需的带宽。流式复制（请参阅第 26.2.5 节）允许更小的数据丢失窗口。
恢复性能足够好，因此备用服务器在激活后通常只需几分钟即可完全可用。因此，这被称为温备配置，它提供了高可用性。从归档的基础备份中恢复服务器并进行回放将花费更长的时间，因此该技术仅提供灾难恢复解决方案，而不是高可用性解决方案。备用服务器也可用于只读查询，在这种情况下，它称为热备服务器。有关更多信息，请参阅第 26.4 节。
通常明智的做法是创建主服务器和备用服务器，使它们尽可能相似，至少从数据库服务器的角度来看是这样。特别是，与表空间关联的路径名将原样传递，因此如果使用此功能，则主服务器和备用服务器必须具有相同的表空间挂载路径。请记住，如果在主服务器上执行CREATE TABLESPACE，则在执行该命令之前，必须在主服务器和所有备用服务器上创建为此所需的任何新的挂载点。硬件不必完全相同，但经验表明，在应用程序和系统的整个生命周期中，维护两个相同的系统比维护两个不同的系统更容易。无论如何，硬件架构必须相同——例如，从 32 位系统传输到 64 位系统将无法工作。
通常，在运行不同主要PostgreSQL发行版级别的服务器之间无法进行日志传输。PostgreSQL 全球开发组的策略是在次要发行版升级期间不更改磁盘格式，因此在主服务器和备用服务器上运行不同的次要发行版级别可能会成功。但是，对此没有提供正式的支持，建议您尽可能使主服务器和备用服务器保持在同一发行版级别。在更新到新的次要发行版时，最安全的策略是首先更新备用服务器——新的次要发行版更有可能能够读取先前次要发行版中的 WAL 文件，反之则不然。
如果服务器在启动时在数据目录中存在 standby.signal 文件，则该服务器将进入备用模式。
在备用模式下，服务器会持续应用从主服务器接收到的 WAL。备用服务器可以从 WAL 归档（请参阅restore_command）或通过 TCP 连接直接从主服务器读取（流式复制）。备用服务器还将尝试还原在备用集群的pg_wal目录中找到的任何 WAL。这通常发生在服务器重新启动后，此时备用服务器会再次回放在重新启动之前从主服务器流式传输的 WAL，但您也可以随时手动将文件复制到pg_wal以使其回放。
在启动时，备用服务器首先还原归档位置中可用的所有 WAL，调用restore_command。一旦到达那里可用的 WAL 的末尾并且restore_command失败，它就会尝试还原pg_wal目录中可用的任何 WAL。如果失败，并且已配置流式复制，则备用服务器会尝试连接到主服务器并从在归档或pg_wal中找到的最后一个有效记录开始流式传输 WAL。如果失败或未配置流式复制，或者如果连接稍后断开，则备用服务器将返回步骤 1 并尝试再次从归档中还原文件。从归档、pg_wal和通过流式复制进行重试的循环将持续进行，直到服务器停止或提升为止。
当运行pg_ctl promote或调用pg_promote()时，备用模式将退出，服务器将切换到正常操作。在故障转移之前，将在归档或pg_wal中立即可用的任何 WAL 都将被还原，但不会尝试连接到主服务器。
在主服务器上设置对备用服务器可访问的归档目录的连续归档，如第 25.3 节中所述。即使主服务器关闭，备用服务器也应能够访问归档位置，即它应该驻留在备用服务器本身或其他受信任的服务器上，而不是在主服务器上。
如果要使用流式复制，请在主服务器上设置身份验证以允许来自备用服务器的复制连接；也就是说，创建一个角色并在pg_hba.conf中提供合适的条目，并将数据库字段设置为replication。还要确保在主服务器的配置文件中将max_wal_senders设置为足够大的值。如果将使用复制槽，请确保max_replication_slots也设置为足够高的值。
如第 25.3.2 节中所述，获取基础备份以引导备用服务器。
要设置备用服务器，请还原从主服务器获取的基础备份（请参阅第 25.3.5 节）。在备用服务器的集群数据目录中创建一个文件standby.signal。将restore_command设置为一个简单的命令，以从 WAL 归档中复制文件。如果您计划为高可用性目的设置多个备用服务器，请确保将recovery_target_timeline设置为latest（默认值），以使备用服务器遵循在故障转移到另一个备用服务器时发生的时序更改。
如果文件不存在，则restore_command应立即返回；如有必要，服务器将再次重试该命令。
如果要使用流式复制，请使用包含主机名（或 IP 地址）以及连接到主服务器所需的任何其他详细信息的 libpq 连接字符串填充primary_conninfo。如果主服务器需要密码进行身份验证，则也需要在primary_conninfo中指定密码。
如果您正在为高可用性目的设置备用服务器，请像主服务器一样设置 WAL 归档、连接和身份验证，因为备用服务器在故障切换后将作为主服务器工作。
如果您使用 WAL 归档，可以使用 archive_cleanup_command 参数删除备用服务器不再需要的文件，从而最大程度地减小其大小。 pg_archivecleanup 实用程序专门设计用于在典型的单备用配置中与 archive_cleanup_command 一起使用，请参阅 pg_archivecleanup。但是请注意，如果您将归档用于备份目的，则需要保留恢复至少最近一次基本备份所需的文件，即使备用服务器不再需要它们。
一个简单的配置示例是
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass options=''-c wal_sender_timeout=5000''' restore_command = 'cp /path/to/archive/%f %p' archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
您可以拥有任意数量的备用服务器，但是如果您使用流复制，请确保在主服务器中将 max_wal_senders 设置得足够高，以允许它们同时连接。
流复制允许备用服务器保持比基于文件的日志传送更及时。备用服务器连接到主服务器，主服务器在生成 WAL 记录时将其流式传输到备用服务器，而无需等待 WAL 文件填满。
流复制默认情况下是异步的（请参阅 第 26.2.8 节），在这种情况下，在主服务器中提交事务与更改在备用服务器中可见之间存在很小的延迟。但是，此延迟远小于基于文件的日志传送，假设备用服务器功能足够强大以跟上负载，通常小于一秒。使用流复制，archive_timeout 不需要减少数据丢失窗口。
如果您使用流复制而不使用基于文件的连续归档，则服务器可能会在备用服务器接收之前回收旧的 WAL 段。如果发生这种情况，则需要从新的基本备份重新初始化备用服务器。您可以通过将 wal_keep_size 设置为足够大的值以确保 WAL 段不会过早回收，或者为备用服务器配置复制槽来避免这种情况。如果您设置了一个备用服务器可以访问的 WAL 归档，则不需要这些解决方案，因为备用服务器始终可以使用归档来赶上，前提是它保留了足够的段。
要使用流复制，请按照 第 26.2 节 中所述设置基于文件的日志传送备用服务器。将基于文件的日志传送备用服务器转换为流复制备用服务器的步骤是将 primary_conninfo 设置指向主服务器。在主服务器上设置 listen_addresses 和身份验证选项（请参阅 pg_hba.conf），以便备用服务器可以连接到主服务器上的 replication 伪数据库（请参阅 第 26.2.5.1 节）。
在支持保持活动套接字选项的系统上，设置 tcp_keepalives_idle、tcp_keepalives_interval 和 tcp_keepalives_count 有助于主服务器及时发现断开的连接。
设置来自备用服务器的并发连接的最大数量（有关详细信息，请参阅 max_wal_senders）。
当备用服务器启动并且 primary_conninfo 正确设置后，备用服务器将在重放归档中可用的所有 WAL 文件后连接到主服务器。如果连接成功建立，您将在备用服务器中看到一个 walreceiver，并在主服务器中看到一个相应的 walsender 进程。
务必设置复制的访问权限，以便只有受信任的用户才能读取 WAL 流，因为从中提取特权信息很容易。备用服务器必须以具有 REPLICATION 权限或超级用户权限的帐户身份向主服务器进行身份验证。建议为复制创建一个具有 REPLICATION 和 LOGIN 权限的专用用户帐户。虽然 REPLICATION 权限提供了非常高的权限，但它不允许用户修改主系统上的任何数据，而 SUPERUSER 权限则允许。
复制的客户端身份验证由 pg_hba.conf 记录控制，该记录在 database 字段中指定 replication。例如，如果备用服务器在主机 IP 192.168.1.100 上运行，并且复制的帐户名为 foo，则管理员可以将以下行添加到主服务器上的 pg_hba.conf 文件中
# Allow the user "foo" from host 192.168.1.100 to connect to the primary # as a replication standby if the user's password is correctly supplied. # # TYPE DATABASE USER ADDRESS METHOD host replication foo 192.168.1.100/32 md5
主服务器的主机名和端口号、连接用户名和密码在 primary_conninfo 中指定。密码也可以在备用服务器上的 ~/.pgpass 文件中设置（在 database 字段中指定 replication）。例如，如果主服务器在主机 IP 192.168.1.50、端口 5432 上运行，复制的帐户名为 foo，密码为 foopass，则管理员可以将以下行添加到备用服务器上的 postgresql.conf 文件中
# The standby connects to the primary that is running on host 192.168.1.50 # and port 5432 as the user "foo" whose password is "foopass". primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
流复制的一个重要健康指标是在主服务器中生成但在备用服务器中尚未应用的 WAL 记录的数量。您可以通过比较主服务器上的当前 WAL 写入位置与备用服务器接收的最后一个 WAL 位置来计算此延迟。这些位置可以使用主服务器上的 pg_current_wal_lsn 和备用服务器上的 pg_last_wal_receive_lsn 分别检索（有关详细信息，请参阅 表 9.95 和 表 9.96）。备用服务器中的最后一个 WAL 接收位置也显示在 WAL 接收器进程的进程状态中，使用 ps 命令显示（有关详细信息，请参阅 第 27.1 节）。
您可以通过 pg_stat_replication 视图检索 WAL 发送器进程的列表。pg_current_wal_lsn 和视图的 sent_lsn 字段之间的较大差异可能表示主服务器负载过重，而 sent_lsn 和备用服务器上的 pg_last_wal_receive_lsn 之间的差异可能表示网络延迟，或者备用服务器负载过重。
在热备用上，可以通过 pg_stat_wal_receiver 视图检索 WAL 接收器进程的状态。pg_last_wal_replay_lsn 和视图的 flushed_lsn 之间的较大差异表示 WAL 的接收速度快于其重放速度。
复制槽提供了一种自动化方式，以确保主服务器在所有备用服务器都接收到 WAL 段之前不会删除它们，并且主服务器不会删除可能导致 恢复冲突 的行，即使备用服务器断开连接也是如此。
作为使用复制槽的替代方法，可以使用 wal_keep_size 阻止删除旧的 WAL 段，或者使用 archive_command 或 archive_library 将段存储在归档中。这些方法的缺点是它们通常会导致保留比所需更多的 WAL 段，而复制槽仅保留已知需要的段数。
类似地，hot_standby_feedback 本身，如果不使用复制槽，则可以防止真空删除相关行，但在备用服务器未连接的任何时间段内都不提供保护。
请注意，复制槽会导致服务器保留如此多的 WAL 段，以至于它们填满了为 pg_wal 分配的空间。max_slot_wal_keep_size 可用于限制复制槽保留的 WAL 文件的大小。
每个复制槽都有一个名称，该名称可以包含小写字母、数字和下划线字符。
可以在 pg_replication_slots 视图中查看现有的复制槽及其状态。
可以通过流复制协议（请参阅 第 53.4 节）或通过 SQL 函数（请参阅 第 9.28.6 节）创建和删除槽。
您可以像这样创建一个复制槽
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
slot_name | lsn
-------------+-----
node_a_slot |
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-------------+-----------+--------
node_a_slot | physical | f
(1 row)
要配置备用服务器以使用此槽，应在备用服务器上配置 primary_slot_name。这是一个简单的示例
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' primary_slot_name = 'node_a_slot'
级联复制功能允许备用服务器接受复制连接并将 WAL 记录流式传输到其他备用服务器，充当中继。这可用于减少到主服务器的直接连接数量，并最大程度地减少站点间带宽开销。
充当接收器和发送器的备用服务器称为级联备用服务器。更直接连接到主服务器的备用服务器称为上游服务器，而更远的备用服务器称为下游服务器。级联复制不对下游服务器的数量或排列施加限制，尽管每个备用服务器仅连接到一个上游服务器，该服务器最终链接到单个主服务器。
级联备用服务器不仅发送从主服务器接收的 WAL 记录，还发送从归档中恢复的 WAL 记录。因此，即使某些上游连接中的复制连接终止，只要有新的 WAL 记录可用，流复制就会继续向下游进行。
级联复制目前是异步的。同步复制（请参阅 第 26.2.8 节）设置目前对级联复制没有影响。
热备用反馈向上游传播，无论级联安排如何。
如果上游备用服务器被提升为新的主服务器，则如果 recovery_target_timeline 设置为 'latest'（默认值），下游服务器将继续从新的主服务器流式传输。
要使用级联复制，请设置级联备机以便它可以接受复制连接（即，设置 max_wal_senders 和 hot_standby，并配置 基于主机的身份验证）。您还需要在下游备机中设置 primary_conninfo 以指向级联备机。
PostgreSQL 流式复制默认是异步的。如果主服务器崩溃，则某些已提交的事务可能尚未复制到备用服务器，从而导致数据丢失。数据丢失量与故障转移时复制延迟成正比。
同步复制提供了确认事务所做的所有更改是否已传输到一个或多个同步备用服务器的功能。这扩展了事务提交提供的标准持久性级别。这种级别的保护在计算机科学理论中被称为 2-安全复制，当 synchronous_commit 设置为 remote_write 时，称为 group-1-safe（group-safe 和 1-safe）。
在请求同步复制时，每个写入事务的提交都将等待确认，直到收到确认消息，确认提交已写入主服务器和备用服务器的磁盘上的预写日志。数据丢失的唯一可能性是主服务器和备用服务器同时发生崩溃。虽然只有在系统管理员谨慎处理这两个服务器的放置和管理时，才能提供更高水平的持久性。等待确认会增加用户对更改在服务器崩溃时不会丢失的信心，但它也必然会增加请求事务的响应时间。最短等待时间为主备服务器之间的往返时间。
只读事务和事务回滚无需等待备用服务器的回复。子事务提交无需等待备用服务器的响应，只有顶级提交才需要。长时间运行的操作（如数据加载或索引构建）不会等到最后的提交消息。所有两阶段提交操作都需要提交等待，包括准备和提交。
同步备用服务器可以是物理复制备用服务器或逻辑复制订阅服务器。它也可以是任何其他知道如何发送适当反馈消息的物理或逻辑 WAL 复制流使用者。除了内置的物理和逻辑复制系统外，还包括诸如 pg_receivewal 和 pg_recvlogical 之类的特殊程序，以及一些第三方复制系统和自定义程序。有关同步复制支持的详细信息，请查看相应的文档。
配置流式复制后，配置同步复制只需要一个额外的配置步骤：必须将 synchronous_standby_names 设置为非空值。 synchronous_commit 也必须设置为 on，但由于这是默认值，因此通常不需要更改。（参见 第 19.5.1 节 和 第 19.6.2 节。）此配置将导致每个提交等待确认备用服务器已将提交记录写入持久存储。 synchronous_commit 可以由各个用户设置，因此可以在配置文件中、针对特定用户或数据库，或由应用程序动态配置，以便控制每个事务的持久性保证。
提交记录写入主服务器磁盘后，WAL 记录将发送到备用服务器。备用服务器在每次将新批次的 WAL 数据写入磁盘时都会发送回复消息，除非在备用服务器上将 wal_receiver_status_interval 设置为零。如果 synchronous_commit 设置为 remote_apply，则备用服务器在重放提交记录时发送回复消息，使事务可见。如果根据主服务器上 synchronous_standby_names 的设置选择备用服务器作为同步备用服务器，则来自该备用服务器的回复消息将与来自其他同步备用服务器的回复消息一起考虑，以决定何时释放等待确认提交记录已接收的事务。这些参数允许管理员指定哪些备用服务器应该是同步备用服务器。请注意，同步复制的配置主要在主服务器上。命名备用服务器必须直接连接到主服务器；主服务器不知道使用级联复制的下游备用服务器。
将 synchronous_commit 设置为 remote_write 将导致每个提交等待确认备用服务器已收到提交记录并将其写入自己的操作系统，但不会等待数据刷新到备用服务器上的磁盘。此设置提供的持久性保证弱于 on：备用服务器可能在操作系统崩溃时丢失数据，尽管不会发生 PostgreSQL 崩溃。但是，它在实践中是一个有用的设置，因为它可以减少事务的响应时间。只有当主服务器和备用服务器都崩溃并且主服务器的数据库同时损坏时，才会发生数据丢失。
将 synchronous_commit 设置为 remote_apply 将导致每个提交等待，直到当前同步备用服务器报告它们已重放事务，使其对用户查询可见。在简单的情况下，这允许使用因果一致性进行负载均衡。
如果请求快速关闭，用户将停止等待。但是，与使用异步复制时一样，服务器在将所有未完成的 WAL 记录传输到当前连接的备用服务器之前，不会完全关闭。
同步复制支持一个或多个同步备用服务器；事务将等待所有被视为同步的备用服务器确认已收到其数据。事务必须等待回复的同步备用服务器的数量在 synchronous_standby_names 中指定。此参数还指定备用服务器名称列表以及从中选择同步备用服务器的方法（FIRST 和 ANY）。
方法 FIRST 指定基于优先级的同步复制，并使事务提交等待，直到其 WAL 记录复制到根据其优先级选择的所需数量的同步备用服务器。列表中较早出现的备用服务器具有较高的优先级，并将被视为同步。此列表中稍后出现的其他备用服务器表示潜在的同步备用服务器。如果任何当前同步备用服务器由于任何原因断开连接，它将立即被下一个优先级最高的备用服务器替换。
基于优先级的多个同步备用服务器的 synchronous_standby_names 示例如下：
synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
在此示例中，如果四个备用服务器 s1、s2、s3 和 s4 正在运行，则将选择两个备用服务器 s1 和 s2 作为同步备用服务器，因为它们的名称在备用服务器名称列表中较早出现。 s3 是一个潜在的同步备用服务器，当 s1 或 s2 出现故障时，它将接管同步备用服务器的角色。 s4 是一个异步备用服务器，因为它的名称不在列表中。
方法 ANY 指定基于仲裁的同步复制，并使事务提交等待，直到其 WAL 记录复制到列表中至少所需数量的同步备用服务器。
基于仲裁的多个同步备用服务器的 synchronous_standby_names 示例如下：
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
在此示例中，如果四个备用服务器 s1、s2、s3 和 s4 正在运行，则事务提交将等待来自 s1、s2 和 s3 中至少两个备用服务器的回复。 s4 是一个异步备用服务器，因为它的名称不在列表中。
可以使用 pg_stat_replication 视图查看备用服务器的同步状态。
同步复制通常需要精心计划和放置备用服务器，以确保应用程序能够正常运行。等待不会使用系统资源，但事务锁将继续保持，直到传输得到确认。因此，不谨慎使用同步复制会降低数据库应用程序的性能，因为响应时间增加和争用更高。
PostgreSQL 允许应用程序开发人员通过复制指定所需的持久性级别。这可以针对整个系统指定，也可以针对特定用户或连接，甚至单个事务指定。
例如，应用程序工作负载可能包括：10% 的更改是重要的客户详细信息，而 90% 的更改是不太重要的数据，如果这些数据丢失，企业更容易恢复，例如用户之间的聊天消息。
通过在应用程序级别（在主服务器上）指定的同步复制选项，我们可以为最重要的更改提供同步复制，而不会减慢大部分总工作负载的速度。应用程序级别选项是重要的实用工具，可以使高性能应用程序受益于同步复制。
您应该考虑网络带宽必须高于 WAL 数据生成率。
synchronous_standby_names 指定了当 synchronous_commit 设置为 on、remote_apply 或 remote_write 时，事务提交将等待回复的同步备用服务器的数量和名称。如果任何一个同步备用服务器崩溃，则此类事务提交可能永远无法完成。
确保您保留尽可能多的请求的同步备用服务器是实现高可用性的最佳解决方案。这可以通过使用 synchronous_standby_names 命名多个潜在的同步备用服务器来实现。
在基于优先级的同步复制中，列表中较早出现的备用服务器将用作同步备用服务器。如果其中一个出现故障，则这些备用服务器之后列出的备用服务器将接管同步备用服务器的角色。
在基于仲裁的同步复制中，列表中出现的备用服务器都将用作同步备用服务器的候选者。即使其中一个出现故障，其他备用服务器也将继续执行同步备用服务器候选者的角色。
当备用服务器第一次连接到主服务器时，它尚未正确同步。这称为 catchup 模式。一旦备用服务器和主服务器之间的延迟首次达到零，我们就进入实时 streaming 状态。备用服务器创建后，初始的赶超时间可能很长。如果备用服务器关闭，则赶超时间将根据备用服务器关闭的时间长度而增加。备用服务器只有在达到 streaming 状态后才能成为同步备用服务器。可以使用 pg_stat_replication 视图查看此状态。
如果主服务器在事务等待确认期间重启，这些等待的事务将在主数据库恢复后被标记为完全提交。无法确定在主服务器崩溃时所有备用服务器是否都收到了所有未完成的WAL数据。某些事务在备用服务器上可能不会显示为已提交，即使它们在主服务器上显示为已提交。我们提供的保证是，在已知所有同步备用服务器安全地接收WAL数据之前，应用程序不会收到事务成功提交的明确确认。
如果您确实无法保留请求的同步备用服务器数量，则应减少事务提交必须等待其响应的同步备用服务器数量，方法是在 synchronous_standby_names 中修改（或禁用它），并在主服务器上重新加载配置文件。
如果主服务器与其余备用服务器隔离，则应故障转移到这些其他剩余备用服务器中最佳的候选者。
如果您需要在事务等待时重新创建备用服务器，请确保在 synchronous_commit = off 的会话中运行函数 pg_backup_start() 和 pg_backup_stop()，否则这些请求将永远等待备用服务器出现。
当在备用服务器中使用持续WAL归档时，存在两种不同的场景：WAL归档可以在主服务器和备用服务器之间共享，或者备用服务器可以拥有自己的WAL归档。当备用服务器拥有自己的WAL归档时，将 archive_mode 设置为 always，并且备用服务器将为其接收到的每个WAL段调用归档命令，无论它是通过从归档中恢复还是通过流式复制接收的。共享归档可以类似地处理，但 archive_command 或 archive_library 必须测试正在归档的文件是否已存在，以及现有文件的内容是否相同。这需要在 archive_command 或 archive_library 中更加小心，因为它必须小心避免用不同内容覆盖现有文件，但如果完全相同的文件被归档两次，则返回成功。并且所有这些都必须在没有竞争条件的情况下完成，如果两台服务器尝试同时归档同一个文件。
如果 archive_mode 设置为 on，则在恢复或备用模式期间不会启用归档程序。如果备用服务器被提升，它将在提升后开始归档，但不会归档任何它自己未生成的WAL或时间线历史文件。要在归档中获取完整的WAL文件系列，您必须确保在WAL到达备用服务器之前已对其进行归档。对于基于文件的日志传送，这本质上是正确的，因为备用服务器只能还原在归档中找到的文件，但如果启用了流式复制则不行。当服务器未处于恢复模式时，on 和 always 模式之间没有区别。
如果您在文档中看到任何不正确的内容，与您使用特定功能的体验不符，或者需要进一步说明，请使用 此表单 报告文档问题。