通常，最好让主库和备库尽可能相似，至少从数据库服务器的角度看应如此。尤其是，与表空间相关的路径名会原样传递，因此如果使用该特性，主库和备库必须为表空间配置完全相同的挂载路径。请记住，如果在主库上执行 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 和流复制重试的循环，会一直持续到服务器停止，或触发文件触发故障切换。

当找到触发器文件（trigger_file）时，备库模式退出，服务器切换到正常操作。在故障转移之前，会恢复归档或pg_xlog中立即可用的所有 WAL，但不会尝试连接到主库。

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

如果想使用流复制，请在主服务器上设置认证，允许来自备服务器的复制连接；也就是在pg_hba.conf中提供适当的条目，把 database 字段设置为replication。还要确保在主服务器的配置文件中把max_wal_senders设置为足够大的值。

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

要设置备服务器，请恢复从主服务器取得的基础备份（见第 24.3.3 节）。在备服务器的集簇数据目录中创建恢复命令文件recovery.conf，并启用standby_mode。把restore_command设置为一个从 WAL 归档复制文件的简单命令。

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

如果是出于高可用目的设置备服务器，请像主服务器一样设置 WAL 归档、连接和认证，因为备服务器在故障转移后将作为主服务器工作。还需要设置trigger_file，使故障转移成为可能。如果是出于报表目的设置备服务器而没有故障转移计划，则不需要trigger_file。

如果使用 WAL 归档，可以借助archive_cleanup_command 参数删除备库不再需要的文件，以尽量缩小归档大小。pg_archivecleanup 工具专门设计用于在典型的单备库配置中与 archive_cleanup_command 配合使用，见 第 F.22 节。不过请注意，如果你还把归档用于备份目的，即使这些文件对备库已经不再需要，也必须至少保留从最新基础备份恢复所需的那些文件。

一个简单的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'
trigger_file = '/path/to/trigger_file'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

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

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

流复制是异步的，因此在主库提交事务到更改在备库中可见之间仍有一小段延迟。不过该延迟比基于文件的日志传送小得多，在备库性能足以跟上负载的情况下通常不到一秒。使用流复制时，不需要用archive_timeout来缩小数据丢失窗口。

如果使用流复制而没有使用基于文件的连续归档，就必须在主库中把wal_keep_segments设置为足够大的值，以确保旧的 WAL 段不会在备库可能仍需要它们追赶时过早回收。如果备库落后太多，就需要用新的基础备份重新初始化。如果你设置了备库可以访问的 WAL 归档，则不需要wal_keep_segments，因为备库总是可以使用归档来追赶。

要使用流复制，请先按 第 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            CIDR-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'