pg_standby — PostgreSQLウォームスタンバイサーバの作成をサポートする
pg_standby [option...] archivelocation nextwalfile walfilepath [restartwalfile]
pg_standbyは「ウォームスタンバイ」データベースサーバの作成をサポートします。 これは、特定の変更が必要となるカスタマイズ可能なテンプレートを持ち、実運用環境で利用可能なプログラムとして設計されています。
pg_standbyは、標準のアーカイブリカバリからウォームスタンバイに切り替えるために必要な待機コマンドrestore_commandとして設計されています。
他の設定も必要ですが、それらはすべてメインのサーバマニュアルで説明されています（26.2を参照してください）。
pg_standbyを使用して待機サーバを構築するには、recovery.conf設定ファイルに以下を追加します。
restore_command = 'pg_standby archiveDir %f %p %r'
ここでarchiveDirは、リストアすべきWALセグメントファイルが存在するディレクトリです。
通常、%rマクロを使用してrestartwalfileが指定された場合、このファイルより論理的に前のすべてのWALファイルはarchivelocationから削除されます。
これによってクラッシュからの再起動ができることを担保しつつ、保持する必要があるファイルの数を最小化します。
archivelocationが、この特定の待機サーバで一時使用用の領域である場合、このパラメータの使用は適切です。
しかし、archivelocationが長期間のWAL保管を目的とした領域である場合には、不適切となります。
pg_standbyは、archivelocationがサーバを所有するユーザから読み取り可能なディレクトリであることを前提とします。
また、restartwalfile（または-k）が指定される場合、archivelocationディレクトリは書き込み可能である必要があります。
マスタサーバが失敗した時の「ウォームスタンバイ」データベースサーバへフェイルオーバーする方法には、以下の2つがあります。
スマートフェイルオーバーは、アーカイブとして利用可能なすべてのWALファイルを適用した後に、待機サーバが準備完了となります。
待機サーバが遅れてもデータロスとなることは全くありませんが、適用されていないWALが大量にある場合、待機サーバが利用可能になるまでには長時間かかるかもしれません。
スマートフェイルオーバーのトリガとなるためには、単語smartを含むトリガファイルを作成するか、単に空のファイルを作成してください。
ファストフェイルオーバーでは、待機サーバはすぐに準備完了となります。
アーカイブ内の未適用のWALファイルは無視され、それらのファイルに記録されていたすべてのトランザクションは失われます。
ファストフェイルオーバーのトリガとなるためには、トリガファイルを作成し、単語fastを書き込んでください。
また、指定した時間内に新しいWALファイルが出現しない場合に、自動的にファストフェイルオーバーを実行するようにpg_standbyを設定することもできます。
pg_standbyは、以下のコマンドライン引数を受け付けます。
-cアーカイブからWALファイルをリストアするために cpまたはcopyコマンドを使用します。
これが唯一サポートされている動作ですので、このオプションには意味はありません。
-dstderrに大量のデバッグログを出力します。
-karchivelocationからファイルを削除することによって、現在のWALファイルよりも古いWALファイルが、ここで指定した数以上アーカイブ内に保持されないようにします。
ゼロ（デフォルト）はarchivelocationからファイルをまったく削除しないことを意味します。
restartwalfileが指定された場合、このパラメータは警告なく無視されます。
アーカイブ内の正確な切り捨て点を決定する際には、そちらの指定方法の方がより正確だからです。
PostgreSQL 8.3の時点では、restartwalfileパラメータによる指定の方が安全、かつ効率的であるため、このパラメータの使用は廃止予定です。
あまりにも小さな値を設定すると、待機サーバの再起動に必要とするファイルも削除されてしまう可能性があり、一方であまりに大きな値を設定するとアーカイブ領域を無駄に消費します。
-r maxretriesコピーが失敗した場合のリトライ回数の最大値を設定します（デフォルトは3です）。
失敗する度に、失敗回数に比例して待ち時間が増加するようにsleeptime * num_retries秒間待機します。
そのため、デフォルトでは待機サーバに失敗を返す前に、5秒、10秒、15秒待機することになります。
これはリカバリの完了と解釈され、その結果としてスタンバイが完全に起動するでしょう。
-s sleeptimeリストアすべきWALがアーカイブ内で見つかるかどうか、その確認をする間隔を秒単位で設定します（最大60秒、デフォルト5秒）。 デフォルト設定は必ずしも推奨するものではありません。 26.2を参考に検討してください。
-t triggerfile存在すればフェイルオーバー発生のきっかけとなるトリガファイルを指定します。
同一システムに複数のサーバが存在する場合、たとえば/tmp/pgsql.trigger.5432などのように構造を持ったファイル名を使用して、どのサーバのトリガか混乱しないようにすることを推奨します。
-V--versionpg_standbyのバージョンを表示して終了します。
-w maxwaittimeファストフェイルオーバー実行後に、次のWALファイルを待機する最大秒数を設定します。 ゼロ（デフォルト）に設定することは永久に待機することを意味します。 デフォルトの設定は必ずしも推奨されません。 26.2を参考にして検討してください。
-?--helppg_standbyのコマンドライン引数に関するヘルプを表示して終了します。
pg_standbyは、PostgreSQL 8.2以降で動作するよう設計されています。
PostgreSQL 8.3は、保持しておく必要がある最後のWALファイルをpg_standbyに渡すための%rマクロを提供しています。
PostgreSQL 8.2では、アーカイブファイルの削除が必要な場合-kオプションを使用しなければなりません。
このオプションは8.3でもまだ利用可能ですが、非推奨です。
PostgreSQL 8.4は、recovery_end_commandオプションを提供しています。
このオプションを指定しないと、残ったトリガファイルが問題を引き起こす可能性があります。
pg_standbyはC言語で書かれており、必要に応じて修正すべき部分が明確に示されているので、修正の容易なソースコードとなっています。
LinuxまたはUnixシステムでは以下のように使用できます。
archive_command = 'cp %p .../archive/%f' restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
ここでは、アーカイブディレクトリは物理的には待機サーバ上にあります。
そのため、archive_commandはNFS経由でアーカイブディレクトリにアクセスします。
しかし、このファイルは（lnの使用を有効にした）待機サーバではローカルです。
そのため、以下のようになります。
standby.logにデバッグ用の出力を書き出します。
次のWALファイルが利用可能になったかどうかを確認するまで2秒間待機します。
/tmp/pgsql.trigger.5442というトリガファイルが出現すると待機状態を解除し、トリガファイルの内容に従ってフェイルオーバーを実行します。
復旧が終了した時点で、トリガファイルを削除します。
必要なくなったファイルをアーカイブディレクトリから削除します。
Windowsでは以下のように使用できます。
archive_command = 'copy %p ...\\archive\\%f' restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log' recovery_end_command = 'del C:\pgsql.trigger.5442'
archive_commandではバックスラッシュを二重にする必要がありますが、restore_commandやrecovery_end_commandでは必要ないことに注意してください。
これは以下のような内容になります。
アーカイブからWALファイルをリストアするためにcopyコマンドを使用します。
standby.logにデバッグ用の出力を書き出します。
次のWALファイルが利用可能になったかどうかを確認するまで5秒間待機します。
C:\pgsql.trigger.5442というトリガファイルが出現すると待機を中止し、トリガファイルの内容に従ってフェイルオーバーを実行します。
復旧が終了した時点で、トリガファイルを削除します。
必要なくなったファイルをアーカイブディレクトリから削除します。
Windowsのcopyコマンドは、ファイルが完全にコピーされる前に、最終的なファイルサイズを設定します。
これは通常pg_standbyを誤動作させます。
したがって、pg_standbyは適切なファイルサイズを見てから、いったんsleeptime秒待ちます。
GNUWin32のcpは、ファイルコピーが完了した後にだけ、ファイルサイズを設定します。
Windowsの例では両方のサーバでcopyを使用していますので、どちらか一方、または両サーバがネットワーク経由でアーカイブディレクトリにアクセスすることになります。
Simon Riggs <simon@2ndquadrant.com>