25.4. 日志传送的替代方法

一种替代在前节描述的内建备用模式的方法是使用restore_command轮询归档位置。 这是只能在8.4及以下版本选择使用。在此设置standby_mode关闭， 因为你要实现备服务器运行你自己所需的轮询。 请参考pg_standby模块关于这类的实现。

请注意在这种模式，服务器将一次应用一个WAL文件，所以如果你使用备服务器对于查询（见热备）， 在主服务器中的动作和当这个动作在备服务器中可见之间有个延迟， 相应的时间用在填写WAL文件。archive_timeout可以使延迟较短。 还要注意你不能用这种方法结合流复制。

主备用服务器上发生的操作是正常的连续归档和恢复任务。 两个数据库服务器相联系的一点是两者共享的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);         /* wait for ~0.1 sec */
    if (CheckForExternalTrigger())
        triggered = true;
}
if (!triggered)
        CopyWALFileForRecovery();

在pg_standby模块中提供一个等待restore_command的实际例子。 应该用来作为参考如何正确地贯彻执行上述逻辑。它也可以扩展需要， 以支持特定的配置和环境。

触发失效切换的方法是规划和设计的一个重要组成部分。 一个潜在的选项是restore_command命令。每个WAL文件执行一次， 但是运行restore_command的进程对于每个文件创建和消亡的， 所以没有守护进程或服务器进程和信号或不能使用的信号处理。 因此，restore_command不适合触发失效切换。使用简单超时机制可能的， 尤其如果与已知的archive_timeout在主服务器上配合设置使用。 尽管，这比较容易出错，因为网络问题或繁忙的主服务器可能有足够的启动失效切换。 如果可以安排，通报机制如显式创建一个触发器文件是理想的。