在主服务器和备用服务器上发生的操作是正常的连续归档和恢复任务。两个数据库服务器之间唯一的联系点是它们共享的WAL文件归档：主服务器将WAL写入归档，备用服务器从归档中读取。必须注意确保来自不同主服务器的WAL归档不会混合在一起或混淆。如果归档仅用于备用操作，则归档无需很大。
使这两个松散耦合的服务器协同工作的魔法只是在备用服务器上使用的restore_command，当请求下一个WAL文件时，它会等待从主服务器可用。正常的恢复处理将从WAL归档中请求文件，如果文件不可用，则报告失败。对于备用处理，下一个WAL文件通常不可用，因此备用必须等待其出现。对于以.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();
触发故障转移的方法是规划和设计的重要部分。一个潜在的选项是restore_command命令。它对于每个WAL文件执行一次，但运行restore_command的进程会为每个文件创建和终止，因此没有守护进程或服务器进程，无法使用信号或信号处理程序。因此，restore_command不适合触发故障转移。可以使用简单的超时机制，特别是与主服务器上已知的archive_timeout设置一起使用时。但是，这种方法有点容易出错，因为网络问题或繁忙的主服务器可能足以启动故障转移。如果可以安排，通知机制例如显式创建触发器文件是理想的。
使用这种替代方法配置备用服务器的简要步骤如下。有关每个步骤的详细信息，请参见前面的各节。
尽可能相同地设置主系统和备用系统，包括两个相同版本的LightDB副本。
从主服务器设置连续归档到备用服务器上的一个WAL归档目录。确保在主服务器上适当设置archive_mode、archive_command和archive_timeout（请参见Section 24.3.1）。
对主服务器进行基本备份（请参见Section 24.3.2），并将此数据加载到备用服务器上。
使用先前描述的等待restore_command（请参见Section 24.3.4）从本地WAL归档开始在备用服务器上恢复。
恢复将WAL归档视为只读，因此一旦将WAL文件复制到备用系统中，它就可以同时被复制到磁带中，就像备用数据库服务器正在读取它一样。因此，在进行高可用性备用服务器运行的同时，可以将文件存储为长期灾难恢复目的。
为了测试目的，可以在同一系统上运行主服务器和备用服务器。这不会提供任何有价值的服务器鲁棒性改进，也不能被描述为高可用性。
使用这种替代方法也可以实现基于记录的日志传送，但这需要定制开发，并且更改仍将只在完整的WAL文件已被传送后对热备查询可见。
外部程序可以调用pg_walfile_name_offset()函数（请参见Section 10.26）来查找当前WAL的结束位置所在的文件名和确切的字节偏移量。然后它可以直接访问WAL文件，并将上次已知的WAL结束位置到当前结束位置之间的数据复制到备用服务器。使用这种方法，数据丢失的窗口是复制程序的轮询周期时间，这可以非常小，从而避免了强制归档部分使用的段文件所浪费的带宽。请注意，备用服务器的restore_command脚本只能处理整个WAL文件，因此增量复制的数据通常不会提供给备用服务器使用。它只有在主服务器死机时才有用-然后在允许它启动之前，将上次的部分WAL文件提供给备用服务器。正确实现此过程需要restore_command脚本与数据复制程序的协作。
从LightDB 9.0版本开始，您可以使用流复制（请参见Section 25.2.5）以更少的工作实现相同的效益。