これまでの節で説明した組み込みのスタンバイモードの他の方法として、アーカイブ場所を順次問い合わせるrestore_commandを使用する方法があります。 これはバージョン8.4以前では唯一の利用可能な選択肢でした。 このリファレンス実装としてpg_standbyを参照してください。

このモードでは、サーバは1度に1つのWALファイルを適用することに注意してください。 このため問い合わせ用にスタンバイサーバを使用する場合(ホットスタンバイを参照)、マスタにおける動作とそれがスタンバイで可視になるまでの間に、WALファイルをみたすために必要とする時間に相当する、遅延が存在します。 archive_timeoutを使用して遅延を短くすることができます。 また、この方法とストリーミングレプリケーションと組み合わせることができないことにも注意してください。

プライマリおよびスタンバイサーバの両方で発生する操作は通常の継続的なアーカイブ処理とリカバリ処理です。 2つのデータベースサーバが連携する唯一の点は、両者が共有するWALファイルのアーカイブです。 プライマリがアーカイブに書き出し、スタンバイがアーカイブから読み取ります。 注意して他のプライマリサーバ由来のWALアーカイブが混在しないことを確実にしなければなりません。 さもないと混乱が発生します。 スタンバイ操作でのみ必要なものですので、アーカイブは必ずしも巨大になりません。

2つの疎結合サーバを協調させる秘訣は簡単で、スタンバイサーバにて使用されるrestore_commandです。 これは次のWALファイルを問い合わせ、それをプライマリから利用可能になるまで待機します。 このrestore_commandはスタンバイサーバのrecovery.confファイルで指定されます。 通常のリカバリ処理は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の実例はpg_standbyモジュール内で提供されています。 これは上記のロジックをどのように正確に実装するかについての参照として使用すべきです。 また、これを特定の設定または環境をサポートするため必要に応じて拡張することができます。

フェイルオーバーを通知する手段は計画・設計段階で重要な部分です。 考えられる選択肢の1つはrestore_commandです。 これは各WALファイルに対して1度実行されるものですが、restore_commandを実行するプロセスは各ファイルに対して起動・終了します。 このようにデーモンやサーバプロセスはありませんので、シグナルやシグナルハンドラを使用することはできません。 したがって、restore_commandはフェイルオーバーの通知には適していません。 特にプライマリサーバ上の既知のarchive_timeout設定と連係して使用できるならば、単純なタイムアウト機能を使用することができます。 しかし、これはネットワーク障害や高負荷なプライマリサーバによりフェイルオーバーが始まってしまうため、どちらかというとエラーになりやすいものです。 実現可能ならば、明示的な通知用ファイルの作成などの通知機構の方が理想的です。