持续归档可用于创建具有一个或多个备用服务器的高可用性 (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）读取 WAL，或直接通过 TCP 连接（流复制）从主服务器读取 WAL。备用服务器还将尝试恢复备用集群的 pg_wal 目录中找到的任何 WAL。这通常发生在服务器重新启动后，备用服务器在重新启动前再次重放从主服务器流式传输的 WAL，但您也可以随时手动将文件复制到 pg_wal 以便进行重放。
启动时，备用服务器将通过调用 restore_command 来恢复归档位置中所有可用的 WAL。一旦到达那里可用的 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 如果文件不存在，应立即返回；服务器将在必要时重试该命令。
如果要使用流复制，请将 primary_conninfo 填充为 libpq 连接字符串，包括主机名（或 IP 地址）以及连接到主服务器所需的任何其他详细信息。如果主服务器需要密码进行身份验证，则必须在 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 节）。
在支持套接字 keepalive 选项的系统上，设置 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 记录控制，该记录在数据库字段中指定 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 文件中设置（在数据库字段中指定 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.97 和 表 9.98）。备用服务器中的最后一个 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（而不使用复制槽）可以防止 vacuum 删除相关行，但在备用服务器未连接的任何时间段内都无法提供保护。
请注意，复制槽可能导致服务器保留过多的 WAL 段，从而填满为 pg_wal 分配的空间。max_slot_wal_keep_size 可用于限制复制槽保留的 WAL 文件的大小。
每个复制槽都有一个名称，该名称可以包含小写字母、数字和下划线字符。
可以在 pg_replication_slots 视图中查看现有的复制槽及其状态。
可以通过流复制协议（请参阅 第 54.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（组安全和 1-安全）。
请求同步复制时，每个写事务的提交将等待确认，即提交已写入主服务器和备用服务器的磁盘写预日志。唯一可能丢失数据的情况是主服务器和备用服务器同时发生崩溃。这可以提供更高水平的持久性，但前提是系统管理员谨慎地放置和管理这两个服务器。等待确认会增加用户对更改不会在服务器崩溃时丢失的信心，但它也必然会增加请求事务的响应时间。最小等待时间是主服务器和备用服务器之间的往返时间。
只读事务和事务回滚不需要等待来自备用服务器的响应。子事务提交不需要等待来自备用服务器的响应，只有顶层提交才需要。长时间运行的操作（如数据加载或索引构建）不会等到最终的提交消息。所有两阶段提交操作都需要等待提交，包括准备和提交。
同步备用服务器可以是物理复制备用服务器或逻辑复制订阅者。它也可以是任何其他物理或逻辑 WAL 复制流使用者，它们知道如何发送适当的反馈消息。除了内置的物理和逻辑复制系统外，这还包括 pg_receivewal 和 pg_recvlogical 等特殊程序，以及一些第三方复制系统和自定义程序。请查看各自的文档以了解同步复制支持的详细信息。
一旦配置了流复制，配置同步复制只需要一个额外的配置步骤：必须将 synchronous_standby_names 设置为非空值。还必须将 synchronous_commit 设置为 on，但由于这是默认值，通常不需要更改。（请参阅 第 19.5.1 节和 第 19.6.2 节。）此配置将导致每个提交等待确认备用服务器已将提交记录写入持久存储。 synchronous_commit 可以由单个用户设置，因此可以针对特定用户或数据库在配置文件中进行配置，或者由应用程序动态配置，以在每个事务的基础上控制持久性保证。
在提交记录写入主服务器磁盘后，WAL 记录随后会发送到备用服务器。除非在备用服务器上将 wal_receiver_status_interval 设置为零，否则备用服务器会在每次将新的 WAL 数据块写入磁盘时发送响应消息。如果 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 模式之间没有区别。
如果您在文档中发现任何不正确之处、与您对特定功能的实际体验不符之处，或者需要进一步澄清之处，请使用 此表单 报告文档问题。