持续归档可以用来创建一个高可用性（HA）集群配置，其中包含一个或多个备用服务器，以便在主服务器发生故障时接管操作。这种能力被广泛称为热备或日志传输。
主服务器和备用服务器协同工作以提供此功能，尽管服务器之间只是松散耦合。主服务器在持续归档模式下运行，而每个备用服务器在持续恢复模式下运行，从主服务器读取 WAL 文件。无需更改数据库表即可启用此功能，因此与其他一些复制解决方案相比，它提供了较低的管理开销。此配置对主服务器的性能影响也相对较小。
直接将 WAL 记录从一个数据库服务器移动到另一个数据库服务器通常被称为日志传输。PostgreSQL 通过一次传输一个文件（WAL 段）的 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 存档读取 WAL（请参阅restore_command）或通过 TCP 连接直接从主服务器读取（流复制）。备用服务器还将尝试恢复在备用集群的 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 记录控制，该记录在 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 接收位置也显示在使用 ps 命令显示的 WAL 接收器进程的进程状态中（有关详细信息，请参阅 第 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 或使用 archive_command 或 archive_library 将段存储在归档中来防止删除旧的 WAL 段。这些方法的一个缺点是，它们通常会导致保留比所需更多的 WAL 段，而复制槽仅保留已知需要的段数。
同样，hot_standby_feedback 本身，而不使用复制槽，可以防止相关行被 vacuum 删除，但在备用服务器未连接的任何时间段内不提供保护。
请注意，复制槽可能会导致服务器保留过多的 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-safe 复制，当 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 模式之间没有区别。
如果您发现文档中有任何不正确的地方，与您使用特定功能的经验不符，或者需要进一步澄清的地方，请使用 此表格报告文档问题。