Postgresql 中文操作指南

通常情况下，最好创建尽可能相似的原始服务器和备用服务器，至少从数据库服务器的角度来看是这样。特别是，与表空间关联的路径名称将直接传递，因此，如果使用了此功能，则原始服务器和备用服务器必须具有相同的表空间装载路径。请记住，如果在原始服务器上执行 CREATE TABLESPACE ，则需要为其创建的任何新装载点必须在命令执行之前先在原始服务器和所有备用服务器上创建。硬件不必完全相同，但经验表明，在应用程序和系统的生命周期中维护两个相同系统比维护两个不同系统更容易。在任何情况下，硬件架构必须相同——例如，从 32 位系统传输到 64 位系统将不起作用。

一般情况下，无法在运行不同主要 PostgreSQL 发行级别的服务器之间进行日志传输。PostgreSQL 全球开发组的策略是，在次要发行升级期间不对磁盘格式进行任何更改，因此在主服务器和备用服务器上运行不同次要发行级别很可能能够成功运行。然而，对此未提供正式的支持，建议您尽可能将主服务器和备用服务器保持在相同的发行级别。当升级到新的次要发行时，最安全的策略是先更新备用服务器——与从较前次要发行读取 WAL 文件相比，较新的次要发行更有可能能够读取较前次要发行的 WAL 文件。

如果在启动服务器时服务器中存在 standby.signal 文件，则服务器将进入备用模式。

在备用模式下，服务器不断应用从主服务器接收的 WAL。备用服务器可以从 WAL 存档（见 restore_command）或直接从主服务器通过 TCP 连接（流复制）读取 WAL。备用服务器还将尝试恢复备用集群 pg_wal 目录中发现的任何 WAL。这通常发生在服务器重新启动之后，当时备用数据库再次重放故障转移之前从主数据库串流的 WAL，但是你也可以随时手动将文件复制到 pg_wal 来重放它们。

在启动时，备用服务器首先从档案库位置恢复所有可用的 WAL，并调用 restore_command。一旦到达那里可用的 WAL 的末尾，且 restore_command 失败，它将尝试恢复 pg_wal 目录中找到的任何 WAL。如果失败，并且已配置流复制，则备用服务器将尝试连接到主服务器，并尝试从存档或 pg_wal 中找到的最后一条有效记录开始流式传输 WAL。如果该尝试失败，或者未配置流复制，或者连接稍后断开，备用服务器将返回步骤 1，并尝试再次从存档恢复文件。此从档案库、pg_wal 和通过流复制进行重试的循环将一直持续到服务器停止或被提升。

当运行 pg_ctl promote 或调用 pg_promote() 时，将退出备用模式，服务器将切换到正常操作。在故障转移之前，将恢复档案库或 pg_wal 中立即可用的任何 WAL，但不尝试连接到主服务器。

在 Section 26.3 中所述的在主数据库上设置连续归档到备用数据库可以访问的归档目录。即使主数据库关闭，备用数据库也应该能够访问归档位置，也就是说，它应该驻留在备用服务器本身或另一个受信任的服务器上，而不是主服务器上。

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

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

要设置备用服务器，请恢复从原始服务器获取的 base 备份（参见 Section 26.3.4 ）。在备用服务器的集群数据目录中创建一个 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 。但请注意，如果您将存档用于备份目的，则需要保留至少最新 base 备份所需的文件，即使备用服务器不再需要这些文件。

配置的一个简单示例是：

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

流复制允许备用服务器比使用基于文件的日志传输更加最新。备用连接到主服务器，它将 WAL 记录流式传输到备用，因为它们被生成，而不等待 WAL 文件被填充。

流复制默认情况下是异步的（见 Section 27.2.8），在这种情况下，在主数据库中提交事务与备用数据库中可见更改之间有一个小的延迟。然而，此延迟远小于基于文件的日志传输，通常在备用数据库足够强大以跟上负载的情况下，小于一秒。使用流复制时，不需要 archive_timeout 来减少数据丢失窗口。

如果您使用流复制而不使用基于文件的连续归档，则服务器可能会在备用接收旧的 WAL 段之前回收旧的 WAL 段。如果发生这种情况，则需要从新的基本备份重新初始化备用。可以通过将 wal_keep_size 设置为足够大的值以确保不会过早回收 WAL 段，或为备用配置复制槽来避免这种情况。如果您设置了备用可访问的 WAL 存档，则不需要这些解决方案，因为如果备用保留足够多的段，则备用始终可以使用存档来追赶。

要使用流复制，请按照 Section 27.2 中所述设置基于文件的日志传输备用服务器。将基于文件的日志传输备用服务器转换为流复制备用服务器的步骤是将 primary_conninfo 设置指向主服务器。在主数据库上设置 listen_addresses 和身份验证选项（见 pg_hba.conf），以便备用服务器可以连接到主服务器上的 replication 伪数据库（见 Section 27.2.5.1）。

在支持保留套接字选项的系统上，设置 tcp_keepalives_idle、 tcp_keepalives_interval 和 tcp_keepalives_count 有助于主数据库及时发现断开的连接。

设置来自备用服务器的最大并发连接数（有关详细信息，请参见 max_wal_senders）。

当备用启动并且 primary_conninfo 设置正确时，备用将在重播存档中可用的所有 WAL 文件后连接到主服务器。如果成功建立连接，您将在备用中看到 walreceiver，以及主服务器中相应的 walsender 进程。

复制槽提供了一种自动化方式，以确保主数据库在备用数据库全部接收 WAL 段后才删除 WAL 段，并且即使备用数据库断开连接，主数据库也不会删除可能导致 recovery conflict 的行。

如果没有使用复制槽，可以使用 wal_keep_size 防止删除旧 WAL 段，或者使用 archive_command 或 archive_library 将 WAL 段存储在存档中。但是，这些方法通常会导致保留比所需更多的 WAL 段，而复制槽只会保留已知需要的段数。另一方面，复制槽可以保留如此多的 WAL 段，以至于它们填满了为 pg_wal 分配的空间； max_slot_wal_keep_size 限制了复制槽保留的 WAL 文件的大小。

类似地， hot_standby_feedback 本身，如果不使用复制槽，可以防止 vacuum 删除相关行，但在备用数据库未连接的任何时间段内，并不提供任何保护。复制槽克服了这些缺点。

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

既作为接收者又作为发送者的备用称为级联备用。更直接连接到主机的备用称为上游服务器，而更“远”的备用服务器称为下游服务器。级联复制不会对下游服务器的数量或排列施加限制，尽管每个备用只连接到一个上游服务器，而上游服务器最终链接到一个主服务器。

级联备用发送的不仅从主接收的 WAL 记录，还包括从存档恢复的 WAL 记录。因此，即使某些上游连接中的复制连接终止，只要有新的 WAL 记录可用，流复制仍会继续进行下游部分。

级联复制当前是异步的。同步复制（见 Section 27.2.8）设置目前对级联复制没有影响。

热备用反馈向上游传播，不管级联的排列如何。

如果上游备用服务器被提升为新的主机，如果将 recovery_target_timeline 设置为 'latest'（默认值），下游服务器将继续从新主机流式传输。

要使用级联复制，请设置级联备用服务器，以便它可以接受复制连接（即，设置 max_wal_senders 和 hot_standby，并配置 host-based authentication）。您还需要在下游备用服务器中设置 primary_conninfo 以指向级联备用服务器。

PostgreSQL 流复制默认是异步的。如果主机服务器崩溃，那么提交的一些事务可能没有复制到备用服务器，这会导致数据丢失。数据丢失的量与故障转移时的复制延迟成正比。

同步复制提供了确认事务所做的所有更改已传输到一个或多个同步备用服务器的功能。这扩展了事务提交提供的那一标准级别的持久性。这种保护级别在计算机科学理论中称为 2 安全复制，在将 synchronous_commit 设置为 remote_write 时称为组 1 安全（组安全和 1 安全）。

在请求同步复制时，每次提交写事务都会等待收到确认，表明该提交已同时写入主机和备用服务器磁盘上的预写日志。唯一可能丢失数据的情况是主机和备用同时发生崩溃。虽然这可以提供更高的持久性级别，但前提是 sysadmin 谨慎安置和管理这两台服务器。等待确认会增加用户对服务器崩溃时更改不会丢失的信心，但也一定会增加请求事务的响应时间。最短等待时间是主机和备用之间的往返时间。

只读事务和事务回滚不必等待备用服务器回复。子事务提交不等待备用服务器回复，只等待顶级提交。诸如数据加载或索引构建之类的长时间操作不等待最后的提交消息。所有两阶段提交操作都需要提交等待，包括准备和提交。

同步备用可以是物理复制备用或逻辑复制订阅者。它还可以是任何其他物理或逻辑 WAL 复制流消费者，该消费者知道如何发送适当的反馈消息。除了内置的物理和逻辑复制系统之外，这还包括诸如 pg_receivewal 和 pg_recvlogical 这样的特殊程序以及一些第三方复制系统和自定义程序。有关同步复制支持的详细信息，请查看相应文档。

在备用服务器中使用连续 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 模式之间没有区别。