25.4. 日志传送的替代方法

一种替代在前节描述的内建备用模式的方法是使用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 在主服务器上配合设置使用。尽管，这有点容易出错，因为网络问题或繁忙的主服务器可能有足够的启动失效切换。 通报机制，如显式创建一个触发器文件是理想的，如果可以安排。