26.2. 日志运输备用服务器

连续归档可用于创建具有一个或多个“备用服务器” 高可用性*(HA)群集配置,如果主服务器发生故障,它们可以接管操作。此功能被广泛称为热备用日志传送

尽管主服务器和备用服务器只是松散耦合的,但它们一起工作以提供此功能。主服务器以连续存档模式运行,而每个备用服务器均以连续恢复模式运行,从主服务器读取 WAL 文件。不需要更改数据库表即可启用此功能,因此与某些其他复制解决方案相比,它提供了较低的 Management 开销。此配置对主服务器的性能影响也相对较低。

直接将 WAL 记录从一台数据库服务器移动到另一台数据库服务器通常被称为日志传送。 PostgreSQL 通过一次传送一个文件(WAL 段)的 WAL 记录来实现基于文件的日志传送。 WAL 文件(16MB)可以在任何距离上轻松,廉价地运送,无论是到相邻系统,同一站点的另一个系统,还是在地球的另一端。此技术所需的带宽根据主服务器的事务速率而变化。基于记录的日志传送更加精细,并且流 WAL 通过网络连接逐渐增加(请参见Section 26.2.5)。

应当注意,日志传送是异步的,即,在事务提交之后传送 WAL 记录。结果,如果主服务器遭受灾难性故障,则存在数据丢失的窗口;尚未发货的 Transaction 将丢失。使用archive_timeout参数可以限制基于文件的日志传送中数据丢失窗口的大小,该参数可以设置为几秒钟。但是,如此低的设置将大大增加文件传送所需的带宽。流复制(请参阅Section 26.2.5)允许较小的数据丢失窗口。

恢复性能足够好,一旦激活备用数据库,备用数据库通常仅需要片刻即可达到完全可用性。因此,这称为提供高可用性的热备份配置。从已存档的基础备份和前滚还原服务器将花费更长的时间,因此该技术仅提供灾难恢复的解决方案,而不是高可用性。备用服务器也可以用于只读查询,在这种情况下,它称为热备服务器。有关更多信息,请参见Section 26.5

26.2.1. Planning

创建主服务器和备用服务器通常是明智的选择,至少从数据库服务器的角度来看,它们应尽可能相似。特别是,与表空间关联的路径名将在未修改的情况下传递,因此,如果使用了该功能,则主服务器和备用服务器必须具有相同的表空间装载路径。请记住,如果在主要服务器上执行CREATE TABLESPACE,则在执行命令之前,必须在主要服务器和所有备用服务器上创建它所需的任何新安装点。硬件不必完全相同,但是经验表明,在应用程序和系统的整个生命周期中,维护两个相同的系统要比维护两个不同的系统容易。在任何情况下,硬件架构都必须相同-从 32 位系统移植到 64 位系统将无法正常工作。

通常,无法在运行不同主要 PostgreSQL 版本的服务器之间进行日志传送。 PostgreSQLGlobal 开发小组的 Policy 是在次要发行版升级期间不要更改磁盘格式,因此在主服务器和备用服务器上运行不同的次要发行版级别可能会成功运行。但是,没有为此提供正式支持,建议您将主服务器和备用服务器尽可能保持在同一发行级别。更新到新的次要版本时,最安全的策略是先更新备用服务器-新的次要版本更可能能够从先前的次要版本中读取 WAL 文件,反之亦然。

26 .2.2. 备用服务器操作

在待机模式下,服务器连续应用从主服务器接收到的 WAL。备用服务器可以从 WAL 存档(请参阅restore_command)中读取 WAL,也可以通过 TCP 连接(流复制)直接从主服务器中读取 WAL。备用服务器还将尝试还原在备用群集的pg_wal目录中找到的所有 WAL。这通常在服务器重启后发生,当备用服务器再次重放在重启之前从主服务器流式传输的 WAL 时,但是您也可以随时手动将文件复制到pg_wal来重放它们。

在启动时,备用数据库通过还原存档位置中可用的所有 WAL 并调用restore_command开始。一旦到达那里可用的 WAL 的结尾并且restore_command失败,它将尝试恢复pg_wal目录中的所有可用 WAL。如果失败,并且已配置流复制,则备用数据库将尝试连接到主服务器,并从存档或pg_wal中找到的最后一个有效记录开始流 WAL。如果失败或未配置流复制,或者如果以后断开了连接,则备用数据库将返回步骤 1,并尝试再次从存档中还原文件。从 Filespg_wal到流复制的重试循环一直进行到服务器停止或触发文件触发故障转移为止。

当运行pg_ctl promote或找到触发文件(trigger_file)时,将退出待机模式,并且服务器将切换到正常操作。故障转移之前,将立即恢复归档或pg_wal中立即可用的所有 WAL,但不会尝试连接到主数据库。

26 .2.3. 为备用服务器准备主服务器

Section 25.3所述,在主数据库上设置连续归档,从备用数据库可访问归档目录。即使主服务器关闭,归档位置也应该可以从备用数据库访问,即它应该位于备用服务器本身或另一个受信任的服务器上,而不是主服务器上。

如果要使用流式复制,请在主服务器上设置身份验证,以允许来自备用服务器的复制连接;也就是说,创建一个角色并在pg_hba.conf中提供适当的条目,并且数据库字段设置为replication。还要确保在主服务器的配置文件中将max_wal_senders设置为足够大的值。如果将使用复制插槽,请确保max_replication_slots也设置得足够高。

按照Section 25.3.2中所述进行基本备份以引导备用服务器。

26 .2.4. 设置备用服务器

要设置备用服务器,请还原从主服务器获取的基本备份(请参阅Section 25.3.4)。在备用数据库的集群数据目录中创建恢复命令文件recovery.conf,然后打开standby_mode。将restore_command设置为一个简单的命令,以从 WAL 存档中复制文件。如果计划具有多个备用服务器以实现高可用性,请将recovery_target_timeline设置为latest,以使备用服务器遵循故障转移到另一个备用服务器时发生的时间轴更改。

Note

请勿将 pg_standby 或类似工具与此处所述的内置待机模式一起使用。如果该文件不存在,则restore_command应立即返回;服务器将在必要时再次重试该命令。有关使用 pg_standby 之类的工具,请参见Section 26.4

如果要使用流复制,请在 lib_q 连接字符串中填写primary_conninfo,包括主机名(或 IP 地址)以及连接到主服务器所需的所有其他详细信息。如果主服务器需要密码进行身份验证,则也需要在primary_conninfo中指定密码。

如果要出于高可用性的目的设置备用服务器,请像主服务器一样设置 WAL 归档,连接和身份验证,因为备用服务器将在故障转移后用作主服务器。

如果您使用的是 WAL 存档,则可以使用archive_cleanup_command参数最小化其大小,以删除备用服务器不再需要的文件。 pg_archivecleanupUtil 专门设计用于在典型的单待机配置中与archive_cleanup_command一起使用,请参阅pg_archivecleanup。但是请注意,如果将存档用于备份目的,则即使从备数据库不再需要这些文件,也至少需要保留从最新基础备份中恢复所需的文件。

recovery.conf的简单示例是:

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

您可以有任意数量的备用服务器,但是如果使用流复制,请确保在主服务器中将max_wal_senders设置得足够高,以允许它们同时连接。

26 .2.5. 流复制

流复制使备用服务器可以比基于文件的日志传送保持最新状态。备用数据库连接到主数据库,主数据库在生成 WAL 记录时将其流传输到备用数据库,而无需 awaitWAL 文件被填充。

默认情况下,流复制是异步的(请参阅Section 26.2.8),在这种情况下,在主数据库中提交事务与更改在备用数据库中可见之间存在很小的延迟。但是,此延迟要比基于文件的日志传送的延迟小得多,通常假设备用服务器的功能足以应付负载,通常不到一秒钟。对于流复制,不需要archive_timeout来减少数据丢失窗口。

如果使用流式复制而没有基于文件的连续归档,则服务器可能会在备用数据库收到旧的 WAL 段之前对其进行回收。如果发生这种情况,则需要从新的基本备份中重新初始化备用数据库。您可以通过将wal_keep_segments设置为足够大的值来确保 WAL 段不被过早回收,或者为备用数据库配置复制插槽来避免这种情况。如果您设置了可从备用数据库访问的 WAL 存档,则不需要这些解决方案,因为只要备用数据库保留足够的段,它就可以始终使用该存档进行追赶。

要使用流复制,请按照Section 26.2中的说明设置基于文件的日志传送备用服务器。将基于文件的日志传送备用数据库转换为流复制备用数据库的步骤是将recovery.conf文件中的primary_conninfo设置设置为指向主服务器。在主服务器上设置listen_addresses和身份验证选项(请参阅pg_hba.conf),以便备用服务器可以连接到主服务器上的replication伪数据库(请参见Section 26.2.5.1)。

在支持 keepalive 套接字选项的系统上,设置tcp_keepalives_idletcp_keepalives_intervaltcp_keepalives_count可以帮助主数据库迅速注意到断开的连接。

设置备用服务器的最大并发连接数(有关详细信息,请参见max_wal_senders)。

启动备用数据库并正确设置primary_conninfo后,备用数据库将在重播存档中所有可用的 WAL 文件后连接到主数据库。如果成功构建连接,您将在备用数据库中看到一个 walreceiver 进程,在主数据库中看到一个相应的 walsender 进程。

26.2.5.1. Authentication

设置复制访问权限非常重要,因为只有受信任的用户才能读取 WAL 流,因为从中提取特权信息很容易。备用服务器必须以超级用户或具有REPLICATION特权的帐户向主服务器进行身份验证。建议创建具有REPLICATIONLOGIN特权的专用用户帐户进行复制。尽管REPLICATION特权提供了很高的权限,但它不允许用户像SUPERUSER特权那样修改主系统上的任何数据。

用于复制的 Client 端身份验证由pg_hba.conf记录控制,该记录在* database *字段中指定replication。例如,如果备用服务器在主机 IP 192.168.1.100上运行,并且复制帐户名是foo,则 Management 员可以将以下行添加到主服务器上的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

主要的主机名和端口号,连接用户名和密码在recovery.conf文件中指定。也可以在备用数据库的~/.pgpass文件中设置密码(在* database *字段中指定replication)。例如,如果主服务器在主机 IP 192.168.1.50,端口5432上运行,复制的帐户名是foo,密码是foopass,则 Management 员可以将以下行添加到备用数据库的recovery.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'

26.2.5.2. Monitoring

流复制的重要健康 Metrics 是在主数据库中生成但尚未在备用数据库中应用的 WAL 记录的数量。您可以通过将主数据库上的当前 WAL 写入位置与备用数据库收到的最后一个 WAL 位置进行比较来计算此延迟。可以分别使用主服务器上的pg_current_wal_lsn和备用服务器上的pg_last_wal_receive_lsn检索这些位置(有关详细信息,请参见Table 9.79Table 9.80)。备用数据库中最后一个 WAL 接收位置也显示在 WAL 接收器进程的进程状态中,该状态使用ps命令显示(有关详细信息,请参见Section 28.1)。

您可以通过pg_stat_replication视图检索 WAL 发送者进程的列表。 pg_current_wal_lsn和视图的sent_lsn字段之间的较大差异可能表明主服务器处于高负载状态,而备用数据库上的sent_lsnpg_last_wal_receive_lsn之间的差异可能表明网络延迟,或者备用数据库处于高负载状态。

26 .2.6. 复制插槽

复制插槽提供了一种自动方式,以确保在所有备用数据库都接收到 WAL 段之前,该主机不会删除它们,并且即使断开备用数据库,主机也不会删除可能导致recovery conflict的行。

代替使用复制插槽,可以使用wal_keep_segments或通过使用archive_command将这些段存储在归档中来防止删除旧的 WAL 段。但是,这些方法通常会导致保留比所需更多的 WAL 段,而复制插槽仅保留已知所需的段数。这些方法的优点是它们限制了pg_wal的空间要求;当前无法使用复制插槽来执行此操作。

类似地,hot_standby_feedbackvacuum_defer_cleanup_age提供保护,以防止相关行被真空移除,但是前者在未连接备用数据库的任何时间段内均不提供保护,而后者通常需要设置为较高的值以提供足够的保护。复制插槽克服了这些缺点。

26 .2.6.1. 查询和操作复制插槽

每个复制插槽都有一个名称,该名称可以包含小写字母,数字和下划线字符。

可以在pg_replication_slots视图中看到现有的复制插槽及其状态。

可以通过流复制协议(请参见Section 52.4)或 SQL 函数(请参见Section 9.26.6)创建和删除插槽。

26 .2.6.2. 配置实例

您可以创建一个复制插槽,如下所示:

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)

要将备用数据库配置为使用此插槽,应在备用数据库的recovery.conf中配置primary_slot_name。这是一个简单的示例:

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
primary_slot_name = 'node_a_slot'

26 .2.7. 级联复制

级联复制功能允许备用服务器接受复制连接,并将 WAL 记录流传输到其他备用服务器,充当中继。这可以用于减少与主服务器的直接连接数,也可以最大程度地减少站点间带宽开销。

同时充当接收方和发送方的备用数据库称为级联备用数据库。与主服务器直接连接的备用服务器称为上游服务器,而距离较远的备用服务器称为下游服务器。级联复制并没有限制下游服务器的数量或排列,尽管每个备用服务器仅连接到一个上游服务器,该服务器最终链接到单个主服务器/主服务器。

级联备用数据库不仅发送从主数据库接收的 WAL 记录,而且还发送从存档恢复的记录。因此,即使某些上游 Connecting 的复制连接终止了,只要有新的 WAL 记录可用,流式复制就 continue 向下游进行。

级联复制当前是异步的。同步复制(请参阅Section 26.2.8)设置目前对级联复制没有影响。

无论级联如何安排,热备用反馈都会向上游传播。

如果将上游备用服务器提升为新的主服务器,并且将recovery_target_timeline设置为'latest',下游服务器将 continue 从新的主服务器流式传输。

要使用级联复制,请设置级联备用数据库,以便它可以接受复制连接(即,设置max_wal_sendershot_standby,并配置host-based authentication)。您还需要在下游备用数据库中设置primary_conninfo以指向级联备用数据库。

26 .2.8. 同步复制

PostgreSQL 流复制默认是异步的。如果主服务器崩溃,则某些已提交的事务可能尚未复制到备用服务器,从而导致数据丢失。数据丢失量与故障转移时的复制延迟成比例。

同步复制提供了确认事务所做的所有更改已转移到一个或多个同步备用服务器的能力。这扩展了事务提交提供的标准持久性级别。在计算机科学理论中,这种保护级别称为 2 安全复制,而当synchronous_commit设置为remote_write时,则称为 1 组安全(组安全和 1 安全)。

请求同步复制时,写入事务的每个提交将一直 await,直到收到确认已将提交写入主服务器和备用服务器磁盘上的预写日志的确认。可能丢失数据的唯一可能性是,如果主备数据库同时遭受崩溃。尽管只有 sysadmin 对两台服务器的放置和 Management 保持谨慎,这才可以提供更高的持久性。await 确认可以提高用户的信心,即在服务器崩溃的情况下所做的更改不会丢失,但这也必定会增加请求事务的响应时间。最小 await 时间是主服务器到备用服务器之间的往返时间。

只读事务和事务回滚无需 await 备用服务器的答复。子事务提交不 await 备用服务器的响应,仅 await 顶级提交。诸如数据加载或索引构建之类的长期运行的操作不会等到最后的提交消息出现。所有两阶段的提交操作都需要提交 await,包括准备和提交。

同步备用数据库可以是物理复制备用数据库或逻辑复制订阅服务器。也可以是知道如何发送适当反馈消息的任何其他物理或逻辑 WAL 复制流使用者。除了内置的物理和逻辑复制系统之外,它还包括诸如pg_receivewalpg_recvlogical之类的特殊程序,以及一些第三方复制系统和自定义程序。查看相应的文档以获取有关同步复制支持的详细信息。

26 .2.8.1. 基本配置

配置流复制后,配置同步复制仅需要一个附加配置步骤:synchronous_standby_names必须设置为非空值。 synchronous_commit也必须设置为on,但是由于这是默认值,因此通常不需要更改。 (请参阅Section 19.5.1Section 19.6.2。)此配置将使每个提交都 await 确认备用数据库已将提交记录写入持久性存储的确认。 synchronous_commit可以由单个用户设置,因此可以在配置文件中为特定用户或数据库配置synchronous_commit,也可以由应用程序动态配置synchronous_commit,以便在每个事务的基础上控制持久性保证。

将提交记录写入主磁盘上的磁盘后,WAL 记录将被发送到备用数据库。每当新一批 WAL 数据写入磁盘时,备用数据库都会发送答复消息,除非在备用数据库上将wal_receiver_status_interval设置为零。在synchronous_commit设置为remote_apply的情况下,备用服务器在重播提交记录时发送答复消息,从而使事务可见。如果将备用数据库选择为同步备用数据库,则根据主数据库上的synchronous_standby_names的设置,将考虑来自该备用数据库的答复消息以及其他同步备用数据库的答复消息,以决定何时释放事务以 await 确认提交记录具有已收到。这些参数使 Management 员可以指定哪些备用服务器应为同步备用服务器。请注意,同步复制的配置主要在主服务器上。命名备用数据库必须直接连接到主数据库;主服务器对使用级联复制的下游备用服务器一无所知。

synchronous_commit设置为remote_write将使每个提交都 await 确认备用数据库已收到提交记录并将其写到其自己的 os 中,但不会 await 将数据刷新到备用数据库的磁盘上。与on相比,此设置提供的持久性更弱:在 os 崩溃的情况下,备用数据库可能会丢失数据,尽管 PostgreSQL 崩溃并非如此。但是,这实际上是一个有用的设置,因为它可以减少事务的响应时间。仅当主数据库和备用数据库崩溃并且主数据库同时损坏时,才会发生数据丢失。

synchronous_commit设置为remote_apply将导致每次提交都 await,直到当前的同步备用数据库报告它们已重播该事务,从而使其对用户查询可见。在简单的情况下,这可以实现因果一致性的负载平衡。

如果请求快速关机,用户将停止 await。但是,就像使用异步复制一样,在所有未完成的 WAL 记录都传输到当前连接的备用服务器之前,服务器不会完全关闭。

26 .2.8.2. 多个同步备用

同步复制支持一台或多台同步备用服务器;事务将 await,直到所有被视为同步的备用服务器都确认收到其数据。 synchronous_standby_names中指定了事务必须 await 答复的同步备用数据库的数量。此参数还指定备用名称列表,以及从列出的备用数据库中选择同步备用数据库的方法(FIRSTANY)。

方法FIRST指定基于优先级的同步复制,并使事务提交 await,直到其 WAL 记录被复制到根据其优先级选择的请求数量的同步备用数据库中。名称在列表中较早出现的备用数据库具有更高的优先级,并将被视为同步数据库。此列表后面出现的其他备用服务器代表潜在的同步备用服务器。如果任何当前同步备用数据库由于某种原因断开连接,它将立即替换为次高优先级备用数据库。

基于优先级的多个同步备用数据库的synchronous_standby_names的示例是:

synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'

在此示例中,如果四个备用服务器s1s2s3s4正在运行,则两个备用服务器s1s2将被选择为同步备用服务器,因为它们的名称出现在备用名称列表的前面。 s3是潜在的同步备用数据库,当s1s2之一发生故障时,它将接替同步备用数据库的角色。 s4是异步备用数据库,因为其名称不在列表中。

方法ANY指定基于仲裁的同步复制,并使事务提交 await,直到它们的 WAL 记录被复制到至少列表中请求的同步备用数据库数量为止。

基于仲裁的多个同步备用数据库的synchronous_standby_names示例为:

synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

在此示例中,如果四个备用服务器s1s2s3s4正在运行,则事务提交将 await 至少s1s2s3两个备用服务器的答复。 s4是异步备用数据库,因为其名称不在列表中。

备用服务器的同步状态可以使用pg_stat_replication视图查看。

26 .2.8.3. 规划绩效

同步复制通常需要精心计划和放置的备用服务器,以确保应用程序的性能令人满意。await 不会占用系统资源,但是事务锁将 continue 保留,直到确认传输为止。结果,由于响应时间增加和争用增加,谨慎使用同步复制将降低数据库应用程序的性能。

PostgreSQL 允许应用程序开发人员指定通过复制所需的持久性级别。尽管也可以为特定用户或连接甚至单个事务指定此名称,但可以为整个系统指定此名称。

例如,应用程序工作负载可能包括:10%的更改是重要的 Client 详细信息,而 90%的更改不是次要的数据,如果业务丢失,则业务可以更轻松地生存下来,例如用户之间的聊天消息。

使用在应用程序级别(在主数据库上)指定的同步复制选项,我们可以为最重要的更改提供同步复制,而不会减慢总工作量。应用程序级别选项是重要的实用工具,可为高性能应用程序提供同步复制的好处。

您应该考虑网络带宽必须高于 WAL 数据的生成速率。

26 .2.8.4. 规划高可用性

synchronous_standby_names指定当将synchronous_commit设置为onremote_applyremote_write将 await 来自其的响应时,事务提交的同步备用数据库的数目和名称。如果任何一个同步备用数据库都应崩溃,则此类事务提交可能永远不会完成。

高可用性的最佳解决方案是确保您保留所需的同步备用数据库数量。这可以通过使用synchronous_standby_names命名多个潜在的同步备用数据库来实现。

在基于优先级的同步复制中,名称在列表中较早出现的备用数据库将用作同步备用数据库。如果当前备用服务器之一出现故障,则在它们之后列出的备用服务器将取代同步备用服务器。

在基于仲裁的同步复制中,列表中出现的所有备用数据库都将用作同步备用数据库的候选项。即使其中一个发生故障,其他备用数据库也将 continue 充当同步备用数据库的候选角色。

当备用数据库首次连接到主数据库时,它将尚未正确同步。这被称为catchup模式。一旦备用数据库和主要数据库之间的时差首次达到零,我们便进入实时streaming状态。创建备用数据库后,追赶时间可能会很长。如果备用数据库已关闭,则追赶时间将根据备用数据库已关闭的时间长度而增加。备用数据库仅在达到streaming状态后才能成为同步备用数据库。可以使用pg_stat_replication视图查看此状态。

如果在提交 await 确认时主服务器重新启动,则一旦主数据库恢复,那些 await 的事务将被标记为完全提交。在主数据库崩溃时,无法确定所有备用数据库都已收到所有未完成的 WAL 数据。有些事务即使在主数据库上也显示为已提交,但在备用数据库上可能未显示为已提交。我们提供的保证是,在已知所有同步备用数据库都安全接收到 WAL 数据之前,应用程序将不会收到对事务成功提交的明确确认。

如果确实不能按要求保留尽可能多的同步备用数据库,则应减少事务提交必须 awaitsynchronous_standby_names中的响应(或禁用它)的同步备用数据库的数量,然后将配置文件重新加载到主服务器上。

如果主服务器与其余的备用服务器隔离开,则应故障切换到其他其余的备用服务器的最佳候选服务器。

如果需要在事务 await 期间重新创建备用服务器,请确保在synchronous_commit = off的会话中运行命令 pg_start_backup()和 pg_stop_backup(),否则这些请求将永远 await 备用数据库出现。

26 .2.9. 待机状态下连续归档

在备用数据库中使用连续 WAL 归档时,有两种不同的方案:WAL 归档文件可以在主数据库和备用数据库之间共享,或者备用数据库可以拥有自己的 WAL 归档文件。当备用数据库拥有自己的 WAL 归档文件时,请将archive_mode设置为always,备用数据库将针对接收到的每个 WAL 段调用归档命令,无论是从归档文件还原还是通过流复制。共享存档可以类似地处理,但是archive_command必须测试正在存档的文件是否已经存在,以及现有文件的内容是否相同。这在archive_command中需要格外小心,因为必须小心不要覆盖内容不同的现有文件,但是如果完全相同的文件被存档两次,则返回成功。如果两台服务器尝试同时存档同一文件,则必须在没有竞争条件的情况下完成所有这些操作。

如果archive_mode设置为on,则在恢复或待机模式下不会启用存档器。如果升级备用服务器,它将在升级后开始存档,但不会存档未生成的任何 WAL。要在归档文件中获得完整的 WAL 文件系列,必须确保所有 WAL 文件都已归档,然后再到达备用数据库。对于基于文件的日志传送,这本质上是正确的,因为备用数据库只能还原在存档中找到的文件,而如果启用了流复制,则不能还原。当服务器不处于恢复模式时,onalways模式之间没有区别。