©
Dokumen ini menggunakan Manual laman web PHP Cina Lepaskan
一种替代在前节描述的内建备用模式的方法是使用restore_command轮询归档位置。 这是只能在8.4及以下版本选择使用。在此设置standby_mode关闭，因为你要实现备服务器运行你自己所需的轮询。 请参考contrib/pg_standby（Section F.28）关于这类的实现。
请注意在这种模式，服务器将一次应用一个WAL文件，所以如果你使用备服务器对于查询（见热备）， 在主服务器中的动作和当这个动作在备服务器中可见之间有个延迟，相应的时间用在填写WAL文件。 还要注意你不能用这种方法结合流复制。
主备用服务器上发生的操作是正常的连续归档和恢复任务。两个数据库服务器相联系的仅有点是两者共享的WAL归档文件： 主写入归档，备从归档读取。必须小心，以确保从单独的主服务器，不会混在一起或混淆WAL归档。归档需要并不大， 如果只是备服务器操作要求。
使松散耦合的两个服务器一起工作简直是奇迹，在备服务器上简单使用restore_command, 当询问下一个WAL文件，等待其为主服务器可用的。在备服务器的recovery.conf文件指定restore_command。 通常恢复进程将从一个WAL归档中请求文件，如果该文件不可用，则报告失败。 对备服务器进程来说下一个WAL文件不可用是正常的，因此备服务器进程需要等待它出现。 对于在.backup或.history文件结束不需要等待，并且返回一个非零值。 等待restore_command可以写为一个自定义脚本，即循环轮询下一个WAL文件的存在。 还必须有一些方法来触发失效切换，应该中断的restore_command，跳出循环，并返回备用服务器一个文件未找到错误。 这两端的恢复和备用服务器，然后将作为一个正常的服务器。
一个合适restore_command的伪码是：
triggered=false;
while(!NextWALFileReady()&&!triggered)
{
sleep(100000L);/*waitfor~0.1sec*/
if(CheckForExternalTrigger())
triggered=true;
}
if(!triggered)
CopyWALFileForRecovery();
一个等待restore_command的工作例子由contrib模块名为pg_standby提供。 应该用来作为参考如何正确地贯彻执行上述逻辑。它也可以扩展需要，以支持特定的配置和环境。
触发失效切换的方法是规划和设计的一个重要组成部分。一个潜在的选项是restore_command命令。 每个WAL文件执行一次，但是运行restore_command的进程对于每个文件创建和消亡的， 所以没有守护进程或服务器进程和信号或不能使用的信号处理。 因此，restore_command不适合触发失效切换。使用简单超时机制可能的，尤其如果与已知的archive_timeout 在主服务器上配合设置使用。尽管，这有点容易出错，因为网络问题或繁忙的主服务器可能有足够的启动失效切换。 通报机制，如显式创建一个触发器文件是理想的，如果可以安排。
配置备用服务器，使用这种替代方法简短步骤如下。 对于每一步的细节，请参阅前面的章节。
建立主备系统尽可能接近相同，包括两个PostgreSQL副本在相同版本级别。
设置从主服务器上连续归档到备服务器WAL归档目录。确保在主服务器上相应的设置archive_mode， archive_command和archive_timeout。
做一个主服务器的基准备份，到备服务器上加载这个数据。（请参阅Section 24.3.2）。
在备服务器上从一个本地的WAL归档开始恢复，如前所述等待使用recovery.conf所指定的restore_command。 （请参阅Section 24.3.3）。
恢复对WAL归档做只读处理，所以一旦在Wal的文件已被复制到备用系统，就可以在同一时间复制到磁带，因为正通过备用数据库服务器读取到。 因此，运行高可用性的备用服务器可以同时作为文件存储长远的灾难恢复目的做处理。
出于测试目的，它是可以在同一系统上运行的主备服务器。 没提供任何值得改进服务器的健壮性，也不会描述为HA。
也有可能实现基于记录的日志传送使用这种替代方法，尽管这需要定制开发，变化仍然只能为热备查询后一个完整的WAL文件传到成为可见的。
一个外部程序可以调用pg_xlogfile_name_offset()这个函数用来找出文件名和当前WAL结尾的准确字节偏移。
然后，可以直接访问WAL文件，并从WAL的上次已知的结尾到当前结束数据复制数据到备用服务器。用这种方法，数据丢失窗口是复制程序的轮询周期时间，
其可以非常小，并没有迫使部分使用的段文件要归档的带宽浪费。请注意备服务器上的restore_command脚本只能处理完整的WAL文件，
所以通常的增量备份数据到备服务器不可用。只有在主服务器死掉，在允许它到来前，最后一部分WAL文件送到备服务器。
在这个进程中的正确实现，需要restore_command脚本与数据复制程序协作。
PostgreSQLversion9.0开始，你可以使用流复制达到事半功倍的效果。 （请参阅Section 25.2.5）。