连续归档可用于创建具有一个或多个备用服务器的高可用性 (HA) 集群配置，以便在主服务器发生故障时接管操作。此功能通常称为“热备用”或“日志传送”。
主服务器和备用服务器协同工作以提供此功能，尽管服务器只是松散耦合的。主服务器以连续归档模式运行，而每个备用服务器以连续恢复模式运行，从主服务器读取 WAL 文件。无需对数据库表进行任何更改即可启用此功能，因此与其他一些复制解决方案相比，它提供了较低的管理开销。此配置对主服务器的性能影响也相对较低。
直接将 WAL 记录从一个数据库服务器移动到另一个数据库服务器通常称为日志传送。PostgreSQL 通过一次传输一个文件（WAL 段）来实现基于文件的日志传送。WAL 文件（16MB）可以轻松且廉价地传输到任何距离，无论是到相邻系统、同一站点中的另一个系统，还是地球另一端的另一个系统。此技术所需的带宽根据主服务器的事务速率而异。基于记录的日志传送更精细，并通过网络连接增量传输 WAL 更改（请参见第 27.2.5 节）。
需要注意的是，日志传送是异步的，即 WAL 记录在事务提交后传送。因此，如果主服务器遭受灾难性故障，则存在数据丢失的窗口；尚未传送的事务将丢失。基于文件日志传送中的数据丢失窗口大小可以通过使用 archive_timeout 参数来限制，该参数可以低至几秒钟。但是，如此低的设置会极大地增加文件传送所需的带宽。流复制（请参见 第 27.2.5 节）允许更小的数据丢失窗口。
恢复性能足够好，一旦激活，备用服务器通常只需片刻即可完全可用。因此，这被称为提供高可用性的热备用配置。从归档基本备份和向前滚动中恢复服务器将花费更长的时间，因此该技术仅为灾难恢复提供解决方案，而不是高可用性。备用服务器还可以用于只读查询，在这种情况下，它被称为热备用服务器。有关更多信息，请参见 第 27.4 节。
通常明智的做法是创建主服务器和备用服务器，以便它们尽可能相似，至少从数据库服务器的角度来看是这样。特别是，与表空间关联的路径名称将原样传递，因此如果使用该功能，主服务器和备用服务器都必须具有相同的表空间装载路径。请记住，如果在主服务器上执行 CREATE TABLESPACE，则在执行命令之前，必须在主服务器和所有备用服务器上创建所需的新装载点。硬件不必完全相同，但经验表明，在应用程序和系统的生命周期内，维护两个相同系统比维护两个不同的系统更容易。无论如何，硬件架构必须相同——例如，从 32 位系统传输到 64 位系统将无法正常工作。
通常，在运行不同主要 PostgreSQL 发行级别的服务器之间进行日志传输是不可能的。PostgreSQL 全球开发组的政策是在小版本升级期间不更改磁盘格式，因此在主服务器和备用服务器上运行不同的小版本很可能会成功。但是，对此没有提供正式支持，建议您尽可能将主服务器和备用服务器保持在相同的发布级别。在更新到新的小版本时，最安全的策略是首先更新备用服务器——新的小版本更有可能能够读取前一个小版本的 WAL 文件，反之亦然。
当服务器启动时，如果数据目录中存在 standby.signal 文件，则服务器进入备用模式。
在备用模式下，服务器会持续应用从主服务器接收的 WAL。备用服务器可以从 WAL 归档中读取 WAL（请参阅 restore_command）或通过 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，但不会尝试连接到主服务器。
在主服务器上设置连续归档到备用服务器可访问的归档目录，如 第 26.3 节 中所述。归档位置应可在主服务器关闭时从备用服务器访问，即它应驻留在备用服务器本身或其他受信任的服务器上，而不应驻留在主服务器上。
如果您想使用流复制，请在主服务器上设置身份验证，以允许来自备用服务器的复制连接；也就是说，创建一个角色并在 pg_hba.conf 中提供一个或多个合适的条目，其中将数据库字段设置为 replication。还要确保在主服务器的配置文件中将 max_wal_senders 设置为足够大的值。如果将使用复制槽，请确保还将 max_replication_slots 设置得足够高。
如 第 26.3.2 节 中所述，进行基本备份以启动备用服务器。
要设置备用服务器，请还原从主服务器获取的基本备份（请参阅 第 26.3.4 节）。在备用服务器的群集数据目录中创建一个文件 standby.signal。将 restore_command 设置为一个简单的命令，以从 WAL 归档中复制文件。如果您计划出于高可用性目的而拥有多个备用服务器，请确保将 recovery_target_timeline 设置为 latest（默认值），以使备用服务器遵循故障转移到另一个备用服务器时发生的 timeline 更改。
如果文件不存在，restore_command 应立即返回；如有必要，服务器将再次重试该命令。
如果您想使用流复制，请使用 libpq 连接字符串填写 primary_conninfo，包括主机名（或 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 文件填满。
流复制默认情况下是异步的（请参阅 第 27.2.8 节），在这种情况下，在主服务器中提交事务和更改在备用服务器中可见之间有一个很小的延迟。但是，此延迟比基于文件的日志传送要小得多，通常在备用服务器足够强大以跟上负载的情况下不到一秒钟。使用流复制，无需 archive_timeout 来减少数据丢失窗口。
如果您在没有基于文件的连续归档的情况下使用流复制，服务器可能会在备用服务器收到 WAL 段之前回收旧的 WAL 段。如果发生这种情况，则需要从新的基本备份中重新初始化备用服务器。您可以通过将 wal_keep_size 设置为足够大的值以确保不会过早地回收 WAL 段，或者为备用服务器配置复制槽来避免这种情况。如果您设置了备用服务器可以访问的 WAL 归档，则不需要这些解决方案，因为只要备用服务器保留足够的段，它就可以始终使用归档来赶上进度。
要使用流复制，请按照 第 27.2 节 中所述设置基于文件的日志传送备用服务器。将基于文件的日志传送备用服务器转换为流复制备用服务器的步骤是将 primary_conninfo 设置指向主服务器。在主服务器上设置 listen_addresses 和身份验证选项（请参阅 pg_hba.conf），以便备用服务器可以连接到主服务器上的 replication 伪数据库（请参阅 第 27.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.91 和 表 9.92）。备用服务器中接收的最后一个 WAL 位置也会显示在 WAL 接收器进程的进程状态中，该状态使用 ps 命令显示（有关详细信息，请参见 第 28.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 段之前不会删除这些段，并且主服务器不会删除可能导致恢复冲突的行，即使备用服务器已断开连接。
除了使用复制槽之外，还可以使用wal_keep_size防止删除旧的 WAL 段，或者使用archive_command或archive_library将这些段存储在存档中。但是，这些方法通常会导致保留比所需更多的 WAL 段，而复制槽仅保留已知需要的段数。另一方面，复制槽可以保留如此多的 WAL 段，以至于它们填满了为pg_wal分配的空间；max_slot_wal_keep_size限制了复制槽保留的 WAL 文件的大小。
同样，hot_standby_feedback本身在不使用复制槽的情况下，可以防止真空删除相关行，但在备用服务器未连接的任何时间段内不提供保护。复制槽克服了这些缺点。
每个复制槽都有一个名称，其中可以包含小写字母、数字和下划线字符。
可以在pg_replication_slots视图中查看现有的复制槽及其状态。
可以通过流复制协议（请参阅第 55.4 节）或通过 SQL 函数（请参阅第 9.27.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 记录可用，流式复制仍会继续在下游进行。
级联复制当前是异步的。同步复制（请参见第 27.2.8 节）设置目前对级联复制无效。
无论级联排列如何，热备用反馈都会向上游传播。
如果上游备用服务器被提升为新主服务器，则下游服务器将继续从新主服务器流式传输，前提是recovery_target_timeline设置为'latest'（默认值）。
要使用级联复制，请设置级联备用服务器，以便它可以接受复制连接（即设置max_wal_senders和hot_standby，并配置基于主机的身份验证）。您还需要在 downstream 备用服务器中设置primary_conninfo，以指向级联备用服务器。
PostgreSQL流式复制默认情况下是异步的。如果主服务器崩溃，则某些已提交的事务可能尚未复制到备用服务器，从而导致数据丢失。数据丢失的量与故障转移时的复制延迟成正比。
同步复制提供确认所有由事务进行的更改已传输到一个或多个同步备用服务器的功能。这扩展了事务提交提供的标准持久性级别。在计算机科学理论中，此保护级别称为 2 安全复制，当synchronous_commit设置为remote_write时，称为组 1 安全（组安全和 1 安全）。
请求同步复制时，每次写入事务提交都会等待确认，确认已将提交写入主服务器和备用服务器磁盘上的预写日志。数据丢失的唯一可能性是主服务器和备用服务器同时发生崩溃。这可以提供更高的持久性级别，但前提是系统管理员谨慎地放置和管理这两台服务器。等待确认会增加用户对服务器崩溃时更改不会丢失的信心，但它必然也会增加请求事务的响应时间。最短等待时间是主服务器和备用服务器之间的往返时间。
只读事务和事务回滚不需要等待备用服务器的答复。子事务提交不需要等待备用服务器的答复，只有顶级提交才需要。数据加载或索引构建等长期运行操作不需要等到最后的提交消息。所有两阶段提交操作都需要提交等待，包括准备和提交。
同步备用可以是物理复制备用或逻辑复制订阅者。它还可以是任何其他物理或逻辑 WAL 复制流使用者，它知道如何发送适当的反馈消息。除了内置的物理和逻辑复制系统外，还包括 pg_receivewal 和 pg_recvlogical 等特殊程序，以及一些第三方复制系统和自定义程序。查看相应文档了解有关同步复制支持的详细信息。
配置流复制后，配置同步复制只需要一个额外的配置步骤：synchronous_standby_names 必须设置为非空值。 synchronous_commit 也必须设置为 on，但由于这是默认值，因此通常不需要进行更改。（请参见 第 20.5.1 节 和 第 20.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 到达备用服务器之前，所有 WAL 都已归档。由于备用服务器只能还原归档中找到的文件，但如果启用了流复制，则并非如此，因此基于文件日志传输本质上是正确的。当服务器不在恢复模式时，on 和 always 模式之间没有区别。