©
Dokumen ini menggunakan Manual laman web PHP Cina Lepaskan
连续归档可以配合随时准备取代失效主服务器的一个或多个备份服务器，用于创建一个高可用性(HA)集群。 这个能力通常被称为热备份或日志传送(LogShipping)。
虽然主服务器和备份服务器只是松散的耦合在一起，但它们必须同时运行。 主服务器以连续归档模式运行，备份服务器以连续恢复模式运行并从主服务器不停的读取WAL文件。 因为数据库的表无需为此进行任何改变，所以与其它复制方法相比，额外的管理开销很小。 并且这种方法对主服务器的性能影响也很小。
直接移动WAL或在数据库服务器之间"传送"日志记录通常被称为日志传送(LogShipping)。 PostgreSQL实现了基于文件的日志传送，意思是WAL记录每次移动一个完整的文件(WAL段)。 WAL文件可以被轻易的在任意两个地点之间传送，不管是与邻近的系统还是地球另一面的系统。 所需带宽取决于主服务器的事务发生速度。 基于记录的日志传送也可以通过Section 25.2.5中讨论的自定义过程实现。
日志传送是异步的，也就是WAL记录在事务提交之后才被传送。 也就是说主服务器遭遇致命故障后尚未传送的事务数据将会丢失。 数据丢失的长度可以使用archive_timeout加以限制，比如限制为几秒钟。 当然这么小的设置也导致了传送带宽的大幅增长。 如果你期望将丢失的数据限制在一分钟之内，可能更好的办法是使用基于记录的日志传送。 参考Section 25.2.5。
因为不停的执行恢复过程，备份服务器在通常情况下是不能被访问的。 由于恢复速度非常快，备份服务器通常在启用后只有很短的时间不能使用。 因此，我们认为这个方案可以作为热备份来提供高可用性。 将服务器从一个已归档的基础备份中恢复将可能耗费大量时间，所以这个方案只能用于灾难恢复而不能用于提供高可用性。
至少从数据库服务器的角度看，创建主服务器和备份服务器并令两者尽可能完全相同是非常明智的。 特别是表空间的路径名必须保持完全一致，这样主服务器和备份服务器就必须拥有同样的表空间挂载路径(如果使用了表空间的话)。 需要记住的是如果在主服务器上执行了CREATE TABLESPACE命令， 那么该命令需要的任何新挂载点必须在执行该命令之前同时在主服务器和备份服务器上创建。 硬件不必完全相同，但是经验显示维护两个完全相同的系统比维护两个不同的系统要少许多麻烦。 无论如何，应尽量保持体系结构相同，比如一个是32-bit系统另一个是64-bit系统将不能正常工作。
通常，在主版本不同的服务器之间传送日志是不可能的，但是次版本不同是可以的，因为它们的磁盘格式相同， 不过我们鼓励你尽可能使用完全相同的版本。 在进行版本升级的时候，正确的做法是首先升级备份服务器， 因为新版本的服务器通常可以读取老版本的WAL文件，但反之则不然
在备用模式，该服务器连续应用从主服务器收取的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，但不做尝试连接主服务器。
在主服务器上设置连续归档到一个备服务器可访问的存档目录，像描述在Section 24.3。 即使主服务器关掉，从备服务器应该可以访问这个归档位置。即它应该驻留在被服务器自身或其它可信赖的服务器，而不是主服务器。
如果你想使用流复制，在主服务器上设置认证，允许从备用服务器复制连接； 在pg_hba.conf提供一个或多个合适项使用数据库字段设置replication。 还要在主服务器的配置文件确保设置max_wal_senders足够大。
启动备用服务器做一个基准备份，描述在Section 24.3.2.
要建立备用服务器，从主服务器恢复基准备份（参阅Section 24.3.3）。 在备用服务器的集群数据目录，创建一个恢复命令文件recovery.conf,开启standby_mode。 设置restore_command为一条从WAL归档复制文件的简单命令。
Note: 不要使用内置在这里描述的备用模式pg_standby或类似的工具。如果该文件不存在，restore_command应该立即返回。 如果必要服务器将再次尝试这个命令。参阅Section 25.4关于使用工具像pg_standby。
如果你想使用流复制，在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足够大允许它们同时连接。
与基于文件日志传送相比，流复制允许保持备服务器更新。 备服务器连接主服务器，其产生的流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发送进程。
复制的访问权限设置是很重要的，所以只有受信任的用户可以读取WAL流，因为很容易从中提取权限信息。 备服务器必须验证作为主服务器的超级用户。所以需要在主服务器上创建一个有SUPERUSER和LOGIN权限的角色。
由一条pg_hba.conf记录指定replication在database字段，控制客户端的复制验证。 例如，如果备服务器是运行在主机IP192.168.1.100和复制时超级用户名为foo，管理员可以在主服务器 pg_hba.conf文件里添加下面行：
#Allowtheuser"foo"fromhost192.168.1.100toconnecttotheprimary #asareplicationstandbyiftheuser'spasswordiscorrectlysupplied. # #TYPEDATABASEUSERCIDR-ADDRESSMETHOD hostreplicationfoo192.168.1.100/32md5
主服务器的主机名和端口号，连接用户名，和在recovery.conf文件指定的密码。 该密码也可以在备服务器的~/.pgpass文件里设置。 （在database字段指定replication）。 例如，如果主服务器是运行的主机IP192.168.1.50,端口号5432, 复制时超管用户名为foo，和密码为foopass，管理员可以在备服务的recovery.conf文件里 添加下面行：
#Thestandbyconnectstotheprimarythatisrunningonhost192.168.1.50 #andport5432astheuser"foo"whosepasswordis"foopass". primary_conninfo='host=192.168.1.50port=5432user=foopassword=foopass'
流复制的一个重要的健康指标是在主服务器生成的WAL记录数，而不是在备服务器应用的数量。
通过比较在主服务器当前WAL写的位置和备服务器收到的最后一个WAL位置，就可以计算出这种滞后。
在主服务器上使用pg_current_xlog_location和在备服务器上使用pg_last_xlog_receive_location
可以分别检索到它们（参阅Table 9-56和Table 9-57关于详细信息）。
在备服务器收到最后的WAL位置也会进程状态的WAL接收进程显示，使用ps命令显示（参阅Section 27.1关于详细信息）。
