通常，最好让主库和备库尽可能相似，至少从数据库服务器的角度看应如此。尤其是，与表空间相关的路径名会原样传递，因此如果使用该特性，主库和备库必须为表空间配置完全相同的挂载路径。请记住，如果在主库上执行 CREATE TABLESPACE，则它所需的任何新挂载点都必须在执行该命令之前先在主库和所有备库上创建好。硬件不必完全相同，但经验表明，在应用和系统的整个生命周期内，维护两个相同的系统要比维护两个不同的系统更容易。无论如何，硬件架构必须相同 — 例如，从 32 位系统向 64 位系统传送日志是不可行的。

一般来说，不能在运行不同主版本 PostgreSQL 的服务器之间传送日志。PostgreSQL 全球开发组的策略是在次版本升级期间不改变磁盘格式，因此主库和备库运行不同次版本通常也能正常工作。不过，这方面并没有正式支持，因此仍建议主库和备库尽量保持在相同的发行级别。当升级到新的次版本时，最安全的策略是先升级备库 — 新的次版本更有可能兼容读取前一个次版本生成的 WAL 文件，反过来则未必。

在备库模式下，服务器会持续应用从主库收到的 WAL。备库可以从 WAL 归档读取 WAL（参见 restore_command），也可以通过 TCP 连接直接从主库读取（流复制）。备库还会尝试恢复其集簇 pg_xlog 目录中找到的所有 WAL。这通常发生在服务器重启后，此时备库会重新重放重启前从主库接收的 WAL；不过，也可以随时手动将文件复制到 pg_xlog 中，让备库重放它们。

启动时，备库首先调用 restore_command，恢复归档位置中所有可用的 WAL。当读到归档中可用 WAL 的末尾，且 restore_command 失败后，它会尝试恢复 pg_xlog 目录中的所有可用 WAL。如果这也失败，且已配置流复制，备库就会尝试连接主库，从归档或 pg_xlog 中找到的最后一条有效记录开始接收 WAL 流。如果连接失败、未配置流复制，或连接后来断开，备库就会返回第一步，再次尝试从归档恢复文件。这种依次从归档、pg_xlog 和流复制重试的循环，会一直持续到服务器停止，或触发文件触发故障切换。

运行 pg_ctl promote 或发现触发文件（trigger_file）时，服务器会退出备库模式，切换到正常运行。在故障切换前，会恢复归档或 pg_xlog 中能立即获取的所有 WAL，但不会尝试连接主库。

如 第 24.3 节 所述，在主库上设置持续归档，将日志归档到备库可访问的归档目录。即使主库宕机，该归档位置也应该对备库可访问；也就是说，它应位于备库本身或另一台可信服务器上，而不是位于主库上。

如果想使用流复制，就需要在主库上配置认证，以允许来自备库的复制连接；也就是说，创建一个角色，并在 pg_hba.conf 中添加一个或多个把数据库字段设置为 replication 的合适项。还要确保主库配置文件中的 max_wal_senders 被设置为足够大的值。如果要使用复制槽，还应确保 max_replication_slots 也设置得足够高。

如 第 24.3.2 节 所述，获取一个基础备份来引导备库。

要配置备库，请恢复从主库取得的基础备份（参见 第 24.3.4 节）。在备库的集簇数据目录中创建恢复命令文件 recovery.conf，并启用 standby_mode。将 restore_command 设为一个从 WAL 归档复制文件的简单命令。如果计划使用多个备库提供高可用，请将 recovery_target_timeline 设为 latest，使备库能够跟随故障切换到另一个备库时发生的时间线变化。

如果希望使用流复制，请在 primary_conninfo 中填写 libpq 连接字符串，包含连接主库所需的主机名（或 IP 地址）及其他信息。如果主库使用密码认证，还需要在 primary_conninfo 中指定密码。

如果你是为了高可用目的设置备库，那么也应像主库一样设置 WAL 归档、连接和认证，因为故障切换后该备库将作为主库工作。

如果使用 WAL 归档，可以借助archive_cleanup_command 参数删除备库不再需要的文件，以尽量缩小归档大小。pg_archivecleanup 工具专门设计用于在典型的单备库配置中与 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 设置得足够高，以允许它们同时连接。

与基于文件的日志传送相比，流复制可以让备库保持得更接近最新状态。备库连接到主库，主库在生成 WAL 记录时就会把它们流式发送给备库，而不必等待 WAL 文件被写满。

默认情况下流复制是异步的（见 第 25.2.8 节），在这种情况下主库上提交一个事务与该变化在备库上变得可见之间存在短暂的延迟。不过这种延迟比基于文件的日志传送方式中要小得多，在备库的能力足以跟得上负载的前提下，延迟通常低于一秒。在流复制中，不需要 archive_timeout 来缩减数据丢失窗口。

如果你使用流复制，但没有启用基于文件的持续归档，服务器可能会在备库收到旧的 WAL 段之前就把它们回收掉。如果发生这种情况，备库就需要重新通过新的基础备份进行初始化。可以通过把 wal_keep_segments 设置得足够大，以确保 WAL 段不会过早被回收，或者为备库配置一个复制槽，从而避免这种情况。如果配置了一个备库可访问的 WAL 归档，就不需要这些方案，因为只要归档保留了足够多的段，备库始终可以利用归档追赶上来。

要使用流复制，请先按 第 25.2 节 所述配置基于文件的日志传送备库。将这种备库转为流复制备库的关键步骤，是在 recovery.conf 文件中设置 primary_conninfo，使其指向主库。在主库上设置 listen_addresses 和认证选项（参见 pg_hba.conf），使备库能够连接主库的 replication 伪数据库（参见 第 25.2.5.1 节）。

在支持 keepalive 套接字选项的系统上，设置 tcp_keepalives_idle、tcp_keepalives_interval 和 tcp_keepalives_count 有助于主库迅速注意到断开的连接。

设置来自备库的最大并发连接数（详见 max_wal_senders）。

备库启动后，如果正确设置了 primary_conninfo，备库会在重放归档中所有可用的 WAL 文件后连接主库。如果连接成功，就会在备库上看到 walreceiver 进程，在主库上看到对应的 walsender 进程。

# 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

# 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_keep_segments 防止旧 WAL 段被删除，或者使用 archive_command 将这些段保存在归档中。不过，这些方法通常会保留多于实际所需的 WAL 段，而复制槽只保留已知必需的段数。这些方法的优点是能限制 pg_xlog 的空间需求；目前使用复制槽还无法做到这一点。

类似地，hot_standby_feedback 和 vacuum_defer_cleanup_age 可以保护相关行，避免它们被清理删除，但前者在备库未连接期间无法提供保护，后者则通常需要设为较大的值才能提供充分保护。复制槽克服了这些缺点。

postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
  slot_name  | xlog_position
-------------+---------------
 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)

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

级联复制特性允许一台备库接受复制连接，并像中继器一样把 WAL 记录流式发送给其他备库。这可以用来减少直接连接到主库的连接数，并使站点间的带宽开销最小化。

一台同时扮演接收者和发送者角色的备库称为级联备库。与主库连接更直接（经过更少级联备库）的备库称为上游服务器，而距离更远的备库称为下游服务器。级联复制并不限制下游服务器的数量和拓扑，不过每台备库只连接到一台上游服务器，而这条链路最终都会通向同一台主库。

级联备库不仅发送从主库接收到的 WAL 记录，也会发送那些从归档中恢复的记录。因此，即使某条上游复制连接被中断，只要仍有新的 WAL 记录可用，下游的流复制就会继续。

级联复制目前是异步的。同步复制（见第 25.2.8 节）设置当前对级联复制无影响。

热备反馈会向上传播，无论级联拓扑如何。

如果某个上游备库被提升为新主库，只要 recovery_target_timeline 设为 'latest'，下游服务器就会继续从新主库接收流。

要使用级联复制，需要把级联备库设置为能够接受复制连接（也就是设置 max_wal_senders 和 hot_standby，并配置 基于主机的认证）。你还需要把下游备库中的 primary_conninfo 设置为指向级联备库。

PostgreSQL 的流复制默认是异步的。如果主库崩溃，则某些已提交的事务可能尚未复制到备库，从而导致数据丢失。数据丢失量与故障切换时的复制延迟成正比。

同步复制能够确认一个事务所做的全部修改已经被传送到一台同步备库。这扩展了事务提交所提供的标准持久性级别。在计算机科学理论中，这种保护级别被称为 2-safe 复制。

请求同步复制时，每个写事务的提交都会等待，直到收到确认，表明该提交已被写入主库和备库磁盘上的事务日志。数据唯一可能丢失的情况，是主库和备库同时崩溃。这可以提供更高的持久性级别，不过前提是系统管理员必须谨慎地部署和管理这两台服务器。等待确认会增强用户对服务器崩溃时更改不会丢失的信心，但也必然会增加请求事务的响应时间。最短等待时间是主库与备库之间的往返时间。

只读事务和事务回滚不需要等待备库的回应。子事务提交也不需要等待备库响应，只有顶层提交才需要等待。数据装载或索引构建等长时间运行的动作，直到最终提交时才会等待。所有两阶段提交操作都需要等待提交，包括准备和提交两个阶段。