PostgreSQL 10.1 手册_部分 III. 服务器管理_第 26 章 高可用、负载均衡和复制_26.4. 日志传送的替代方法

前一节描述的内建后备模式的一种替代方案是使用一个轮询归档位置的 restore_command。这是版本 8.4 及以下版本中唯一可用的选项。 在这种设置中，设置standby_mode为关闭， 因为你要自行实现后备操作所需的轮询。关于这种实现的一个参考请见 pg_standby模块。

注意在这种模式中，服务器将一次应用一整个文件的 WAL， 因此如果你使用后备服务器来查询（见热备）， 那么主服务器上的一个动作和后备服务器上该动作变得可见之间会有一个延迟， 该延迟对应着填满 WAL 文件的时间。archive_timeout 可以被用来缩短该延迟。还要注意你不能把流复制和这种方法组合起来使用。

在主服务器和后备服务器上都会发生的操作是通常的连续归档和恢复任务。 两个数据库服务器之间唯一的接触点是两者共享的 WAL 文件归档： 主服务器写这个归档，后备服务器读取这个归档。 必须要小心地保证来自独立主服务器的 WAL 归档不会混合在一起或者混淆。 如果归档只被后备操作需要，它不必很大。

使得两台松耦合的服务器一起工作的诀窍是在后备服务器上使用的 restore_command，当要求下一个 WAL 文件时， 会等待它在主服务器上变得可用。restore_command在后备服务器的recovery.conf文件中指定。正常的恢复处理将从 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设置一起。但是， 由于一个网络问题或者繁忙的主服务器可能足以发起故障转移，这有点容易产生错误。 如果可以安排，一种提醒机制（例如显式创建一个触发器文件）是最理想的。