25.2.1. 规划

至少从数据库服务器的角度看，创建主服务器和备份服务器并令两者尽可能完全相同是非常明智的。 特别是表空间的路径名必须保持完全一致，这样主服务器和备份服务器就必须拥有同样的表空间挂载路径(如果使用了表空间的话)。 需要记住的是如果在主服务器上执行了CREATE TABLESPACE命令， 那么该命令需要的任何新挂载点必须在执行该命令之前同时在主服务器和备份服务器上创建。 硬件不必完全相同，但是经验显示维护两个完全相同的系统比维护两个不同的系统要少许多麻烦。 无论如何，应尽量保持体系结构相同，比如一个是32-bit系统另一个是64-bit系统将不能正常工作。

通常，在主版本不同的服务器之间传送日志是不可能的，但是次版本不同是可以的，因为它们的磁盘格式相同， 不过我们鼓励你尽可能使用完全相同的版本。 在进行版本升级的时候，正确的做法是首先升级备份服务器， 因为新版本的服务器通常可以读取老版本的WAL文件，但反之则不然

25.2.2. 备用服务器操作

在备用模式，该服务器连续应用从主服务器收取的WAL。备服务器可以从一个WAL归档（参阅restore_command）或 直接通过一个TCP连接（流复制）从主服务器上读取WAL。备服务器也可以在备用集群pg_xlog尝试查找恢复任何WAL。 这通常发生在服务器重启后，当备服务器重播，在备服务器重启前，从主服务器流复制的WAL，但是你也可以手工复制文件到pg_xlog， 在任何时候可以重播它们。

在启动，备服务器恢复可用在所有的WAL开始存档位置,调用restore_command。 一旦它到达可用WAL的结束，restore_command失败，将尝试恢复pg_xlog目录下任何可用的WAL。 如果那也失败了，并且已经配置了流复制，则尝试连接到主服务器，从在归档或pg_xlog找到最后一条有效的记录开始WAL流。 如果那也失败了，或没有配置流复制，或连接断开，备服务器再次回到步骤1，循环尝试从归档里恢复文件。从归档，pg_xlog， 通过连续流复制直到服务器停止或有触发器文件触发的失效切换时。

当找到一个触发文件（trigger_file）时，退出备用模式并且服务器切换到正常运行。在失效切换前，将立即恢复归档或pg_xlog 任何可用的WAL，但不做尝试连接主服务器。

25.2.3. 为备用服务器准备主服务器

在主服务器上设置连续归档到一个备服务器可访问的存档目录，像描述在Section 24.3。 即使主服务器关掉，从备服务器应该可以访问这个归档位置。即它应该驻留在被服务器自身或其它可信赖的服务器，而不是主服务器。

如果你想使用流复制，在主服务器上设置认证，允许从备用服务器复制连接； 在pg_hba.conf提供一个或多个合适项使用数据库字段设置replication。 还要在主服务器的配置文件确保设置max_wal_senders足够大。

启动备用服务器做一个基准备份，描述在Section 24.3.2.

25.2.4. 建立备用服务器

要建立备用服务器，从主服务器恢复基准备份（参阅Section 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的。 请注意不过，如果你使用备份目的归档，你仍要保留需要恢复的至少最新的基准备份文件，即使备服务器不再需要。

recovery.conf一个简单例子是：

standby_mode='on'
primary_conninfo='host=192.168.1.50port=5432user=foopassword=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足够大允许它们同时连接。

25.2.5. 流复制

与基于文件日志传送相比，流复制允许保持备服务器更新。 备服务器连接主服务器，其产生的流WAL记录到备服务器，而不需要等待填写WAL文件。

流复制是异步的，所以在主事务提交和变化成为在备服务器可见之间,还有一个小的延迟。 这个延迟远小于基于文件日志传送，通常1秒内足够与负载保持。使用流复制，为减少数据丢失窗口 archive_timeout不是必要的。

如果使用流复制而不是基于文件连续归档，你要在主服务器设置wal_keep_segments为 一个足够大的值以使不太早的回收旧WAL段，当备服务器可能仍需要它们赶上。如果备服务器落后太多， 需要用一个新基准备份重新初始化。如果你设置一个备服务器可访问的WAL归档，wal_keep_segments是不必要的， 作为备服务器总是使用归档来赶上。

要使用流复制，建立一个基于文件的日志传送备服务器描述在Section 25.2。 该步将一个基于文件的日志传送备服务器转为流复制备服务器，在recovery.conf文件中设置primary_conninfo 指向主服务器。在主服务器上设置listen_addresses和身份验证选项（见pg_hba.conf），因此备用服务器 可以连接到在主服务器的replication伪数据库（参阅Section 25.2.5.1）。

在系统上支持保持活动的的套接字选项，设置tcp_keepalives_ idle， tcp_keepalives_interval和tcp_keepalives_count帮助主机及时发现断开的连接。

设置备用服务器的最大并发连接数。（参阅max_wal_senders关于详细信息）。

当启动了备服务器并且正确设置了primary_conninfo,该备服务器在回放所有可用的WAL文件后，将连接到主服务器。 如果成功建立了该连接，你将在备服务器中看到WAL接收进程，并且在主服务器相应的一个WAL发送进程。

#Allowtheuser"foo"fromhost192.168.1.100toconnecttotheprimary
#asareplicationstandbyiftheuser'spasswordiscorrectlysupplied.
#
#TYPEDATABASEUSERCIDR-ADDRESSMETHOD
hostreplicationfoo192.168.1.100/32md5

#Thestandbyconnectstotheprimarythatisrunningonhost192.168.1.50
#andport5432astheuser"foo"whosepasswordis"foopass".
primary_conninfo='host=192.168.1.50port=5432user=foopassword=foopass'