持续存档可用于创建高可用性（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 连接从主服务器（流复制）读写 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 应立即返回；如果需要，服务器将再次重试此命令。
如果您想使用流复制，请通过 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 文件填满。
流复制在默认情况下是异步的（请参见第 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 本身（不使用复制槽）可以防止相关行被 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。 voici une example simple
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' primary_slot_name = 'node_a_slot'
级联复制功能允许备用服务器接受复制连接并将 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”状态。在创建备用之后，catch-up 持续时间可能会很长。如果关闭备用，那么 catch-up 时间段将根据备用关闭的时间而增加。备用只有在达到“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 模式之间是没有区别的。