创建主服务器和后备服务器通常是明智的，因此它们可以尽可能相似， 至少从数据库服务器的角度来看是这样。特别地， 与表空间相关的路径名将被未经修改地传递，因此如果该特性被使用， 主、备服务器必须对表空间具有完全相同的挂载路径。 记住如果CREATE TABLESPACE在主服务器上被执行， 在命令被执行前，它所需要的任何新挂载点必须在主服务器和所有后备服务器上先创建好。 硬件不需要完全相同，但是经验显示， 在应用和系统的生命期内维护两个相同的系统比维护两个不相似的系统更容易。 在任何情况下硬件架构必须相同 — 从一个 32 位系统传送到一个 64 位系统将不会工作。

通常，不能在两个运行着不同主版本PostgreSQL的服务器之间传送日志。 PostgreSQL 全球开发组的策略是不在次版本升级中改变磁盘格式， 因此在主服务器和后备服务器上运行不同次版本将会成功地工作。不过， 在这方面并没有提供正式的支持，因此我们建议让主备服务器上运行的版本尽可能相同。 当升级到一个新的次版本时，最安全的策略是先升级后备服务器 — 一个新的次版本发行更可能兼容从前一个次版本读取 WAL 文件。

在后备模式中，服务器持续地应用从主控服务器接收到的 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被运行或一个触发器文件被找到 （trigger_file），后备模式会退出并且服务器会切换到普通操作。 在故障转移之前，在归档或pg_wal中立即可用的任何 WAL 将被恢复， 但不会尝试连接到主控机。

如第 25.3 节中所述， 在主服务器上设置连续归档到一个后备服务器可访问的归档目录。 即使主服务器垮掉该归档位置也应当是后备服务器可访问的， 即它应当位于后备服务器本身或者另一个可信赖的服务器，而不是位于主控服务器上。

如果你想要使用流复制，在主服务器上设置认证来允许来自后备服务器的复制连接。 即创建一个角色并且在pg_hba.conf中提供一个或多个数据库域被设置为 replication的项。还要保证在主服务器的配置文件中 max_wal_senders被设置为足够大的值。如果要使用复制槽， 请确保max_replication_slots也被设置得足够高。

按第 25.3.2 节所述取得一个基础备份来引导后备服务器。

要建立后备服务器，恢复从主服务器取得的基础备份（第 25.3.4 节）。 在后备服务器的集簇数据目录中创建一个恢复命令文件recovery.conf， 并且打开standby_mode。将restore_command 设置为一个从 WAL 归档中复制文件的简单命令。 如果你计划为了高可用性目的建立多个后备服务器， 将recovery_target_timeline设置为latest 来使得该后备服务器遵循发生在故障转移到另一个后备服务器之后发生的时间线改变。

如果你想要使用流复制，在primary_conninfo 中填入一个 libpq 连接字符串，其中包括主机名（或 IP 地址） 和连接到主服务器所需的任何附加细节。如果主服务器需要一个口令用于认证， 口令也应该被指定在primary_conninfo中。

如果你正在为高性能目的建立后备服务器，像主服务器一样建立 WAL 归档、 连接和认证，因为在故障转移后该后备服务器将作为一个主服务器工作。

如果你正在使用一个 WAL 归档，可以使用archive_cleanup_command 参数来移除后备服务器不再需要的文件，这样可以最小化 WAL 归档的尺寸。 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 文件被填充。

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

如果你使用的流复制没有基于文件的连续归档，该服务器可能在后备机收到 WAL 段之 前回收这些旧的 WAL 段。如果发生这种情况，后备机将需要重新从一个新的基础备 份初始化。通过设置wal_keep_segments为一个足够高的值来确保旧 的 WAL 段不会被太早重用或者为后备机配置一个复制槽，可以避免发生这种情况。如 果设置了一个后备机可以访问的 WAL 归档，就不需要这些解决方案，因为该归档可以 为后备机保留足够的段，后备机总是可以使用该归档来追赶主控机。

要使用流复制，按第 26.2 节所述建立一个基于文件的日志传送后备服务器。 将一个基于文件日志传送后备服务器转变成流复制后备服务器的步骤是把 recovery.conf文件中的primary_conninfo设置指向主服务器。 设置主服务器上的listen_addresses和认证选项 （见pg_hba.conf），这样后备服务器可以连接到主服务器上的伪数据库 replication（见第 26.2.5.1 节）。

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

设置来自后备服务器的并发连接的最大数目 （详见max_wal_senders）。

当后备服务器被启动并且primary_conninfo被正确设置， 后备服务器将在重放完归档中所有可用的 WAL 文件之后连接到主服务器。 如果连接被成功建立，你将在后备服务器中看到一个 walreceiver 进程， 并且在主服务器中有一个相应的 walsender 进程。

# 允许来自 192.168.1.100 的用户 "foo" 在提供了正确的口令时作为一个
# 复制后备机连接到主控机。
#
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     foo             192.168.1.100/32        md5

# 后备机要连接到的主控机运行在主机 192.168.1.50 上，
# 端口号是 5432，连接所用的用户名是 "foo"，口令是 "foopass"。
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

复制槽提供了一种自动化的方法来确保主控机在所有的后备机收到 WAL 段 之前不会移除它们，并且主控机也不会移除可能导致 恢复冲突的行，即使后备机断开也是如此。

作为复制槽的替代，也可以使用wal_keep_segments 阻止移除旧的 WAL 段，或者使用archive_command 把段保存在一个归档中。不过，这些方法常常会导致保留的 WAL 段比需要的 更多，而复制槽只保留已知所需要的段数量。这些方法的一个优点是它们为 pg_wal的空间需求提供了界限，但目前使用复制槽无法做到。

类似地，hot_standby_feedback和 vacuum_defer_cleanup_age保护了相关行不被 vacuum 移除，但是前者在后备机断开期间无法提供保护，而后者则需要被设置为一个很高 的值以提供足够的保护。复制槽克服了这些缺点。

postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
  slot_name  | lsn
-------------+-----
 node_a_slot |

postgres=# SELECT * FROM pg_replication_slots;
  slot_name  | slot_type | datoid | database | active | xmin | restart_lsn | confirmed_flush_lsn
-------------+-----------+--------+----------+--------+------+-------------
 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 记录可用，下游的流复制都会继续下去。

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

不管在什么样的级联布置中，热备反馈都会向上游传播。

如果一台上游后备服务器被提升为新的主控机，且下游服务器的 recovery_target_timeline被设置成'latest'， 下游服务器将继续从新的主控机得到流。

要使用级联复制，要建立级联后备服务器让它能够接受复制连接（即设置 max_wal_senders和hot_standby， 并且配置基于主机的认证）。 你还将需要设置下游后备服务器中的primary_conninfo指向级联后备服务器。

PostgreSQL流复制默认是异步的。如果主服务器崩溃， 则某些已被提交的事务可能还没有被复制到后备服务器，这会导致数据丢失。 数据的丢失量与故障转移时的复制延迟成比例。

同步复制能够保证一个事务的所有修改都能被传送到一台同步后备服务器。 这扩大了由一次事务提交所提供的标准持久化级别。 在计算机科学理论中这种保护级别被称为 2-safe 复制。

在请求同步复制时，一个写事务的每次提交将一直等待， 直到收到一个确认表明该提交在主服务器和后备服务器上都已经被写入到磁盘上的预写日志中。 数据会被丢失的唯一可能性是主服务器和后备服务器在同一时间都崩溃。 这可以提供更高级别的持久性，尽管只有系统管理员要关心两台服务器的放置和管理。 等待确认提高了用户对于修改不会丢失的信心， 但是同时也不必要地增加了对请求事务的响应时间。 最小等待时间是在主服务器和后备服务器之间的来回时间。

只读事务和事务回滚不需要等待后备服务器的回复。 子事务提交也不需要等待后备服务器的响应，只有顶层提交才需要等待。 长时间运行的动作（如数据载入或索引构建）不会等待最后的提交消息。 所有两阶段提交动作要求提交等待，包括预备和提交。

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

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

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

当在备用数据库中使用连续WAL归档时，有两种不同的情况： WAL归档可以在主数据库和备用数据库之间共享，或者备用数据库可以有自己的WAL归档。 当备用数据库具有自己的WAL归档时，将archive_mode设置为 always，并且备用数据库将为每个收到的WAL段调用归档命令， 无论是从归档恢复或通过流复制。可以类似地处理共享归档，但是 archive_command必须测试正在归档的文件是否已存在， 以及现有文件是否具有相同的内容。这需要在archive_command 中更加小心，因为它必须小心不要覆盖具有不同内容的现有文件， 但如果完全相同的文件存档两次，则返回成功。 如果两个服务器试图同时归档同一个文件，则所有必须无竞争的完成。

如果archive_mode设置为on， 则在恢复或者待机模式期间不会启用归档程序。如果备用服务器已升级， 它将在升级后开始归档，但不会归档其未生成的任何WAL。 要在归档中获取完整的WAL文件系列，必须确保所有WAL在到达备用数据库之前都已存档。 这对于基于文件的日志传送是固有的，因为备用数据库只能恢复在归档中找到的文件， 但是如果启用了流复制，则不会。当服务器不处于恢复模式时， on和always模式之间没有区别。