# 25.4\. 日志传送的替代方法 一种替代在前节描述的内建备用模式的方法是使用`restore_command`轮询归档位置。 这是只能在8.4及以下版本选择使用。在此设置`standby_mode`关闭， 因为你要实现备服务器运行你自己所需的轮询。 请参考[pg_standby](#calibre_link-1620)模块关于这类的实现。 请注意在这种模式，服务器将一次应用一个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](#calibre_link-1620)模块中提供一个等待`restore_command`的实际例子。 应该用来作为参考如何正确地贯彻执行上述逻辑。它也可以扩展需要， 以支持特定的配置和环境。 触发失效切换的方法是规划和设计的一个重要组成部分。 一个潜在的选项是`restore_command`命令。每个WAL文件执行一次， 但是运行`restore_command`的进程对于每个文件创建和消亡的， 所以没有守护进程或服务器进程和信号或不能使用的信号处理。 因此，`restore_command`不适合触发失效切换。使用简单超时机制可能的， 尤其如果与已知的`archive_timeout`在主服务器上配合设置使用。 尽管，这比较容易出错，因为网络问题或繁忙的主服务器可能有足够的启动失效切换。 如果可以安排，通报机制如显式创建一个触发器文件是理想的。 ## 25.4.1\. 实施 配置备用服务器，使用这种替代方法简短步骤如下。对于每一步的细节， 请参阅前面的章节。 1. 建立主备系统尽可能接近相同，包括两个PostgreSQL副本在相同版本级别。 2. 设置从主服务器上连续归档到备服务器WAL归档目录。 确保在主服务器上相应的设置[archive_mode](#calibre_link-1038), [archive_command](#calibre_link-467)和[archive_timeout](#calibre_link-468)。 (参阅[Section 24.3.1](#calibre_link-1435))。 3. 做一个主服务器的基准备份(参阅[Section 24.3.2](#calibre_link-1632))， 在备服务器上加载这个数据。 4. 在备服务器上从一个本地的WAL归档开始恢复， 如前所述等待使用`recovery.conf`所指定的`restore_command`。 （请参阅[Section 24.3.4](#calibre_link-1634)）。 恢复对WAL归档做只读处理，所以一旦在WAL的文件已被复制到备用系统， 就可以在同一时间复制到磁带，因为正通过备用数据库服务器读取。 因此，运行高可用性的备用服务器可以同时作为文件存储长远的灾难恢复目的做处理。 出于测试目的，它是可以在同一系统上运行的主备服务器。 没提供任何值得改进服务器的健壮性，也不会描述为HA。 ## 25.4.2\. 基于记录的日志传送 使用这种替代方法也有可能实现基于记录的日志传送， 尽管这需要定制开发，一个完整的WAL文件传送之后变化只为热备查询可见。 一个外部程序可以调用`pg_xlogfile_name_offset()`（参阅[Section 9.26](#calibre_link-1334)） 这个函数用来找出文件名和当前WAL结尾的准 确字节偏移。然后，可以直接访问WAL文件， 并从WAL的上次已知的结尾到当前结束数据复制数据到备用服务器。用这种方法， 数据丢失窗口是复制程序的轮询周期时间， 其可以非常小， 并没有迫使部分使用的段文件要归档的带宽浪费。 请注意备服务器上的`restore_command`脚本只能处理完整的WAL文件， 所以通常的增量备份数据到备服务器不可用。只有在主服务器死掉— 在允许它到来前，最后一部分WAL文件送到备服务器。在这个进程中的正确实现， 需要`restore_command`脚本与数据复制程序协作。 PostgreSQL9.0版本开始， 你可以使用流复制达到事半功倍的效果（请参阅[Section 25.2.5](#calibre_link-1048)）。