pg_standbyは"ウォームスタンバイ"データベースサーバの作成をサポートします。 これは、特定の変更が必要となるカスタマイズ可能なテンプレートを持つ、製品レベルのプログラムなるように設計されました。
pg_standbyは、標準のアーカイブリカバリからウォームスタンバイに切り替わるために必要とされるrestore_commandを待機するものとして設計されています。 他の設定も必要ですが、主サーバマニュアルにすべての情報が説明されています（項24.4を参照してください）。
pg_standbyの機能は以下のとおりです。
WALファイルのリストアに関してコピーまたはリンクをサポートします。
C言語で作成されています。 移植性が優れ、インストールが簡単です。
ソースの変更が簡単です。 特に独自の必要性によって変更すべき部分が限定されています。
LinuxとWindowsで試験済みです。
pg_standbyを使用してスタンドバイサーバを構築するには、recovery.conf設定ファイルに以下を追加します。
restore_command = 'pg_standby archiveDir %f %p %r'
ここでarchiveDirは、リストアすべきWALセグメントファイルが存在するディレクトリです。
pg_standbyコマンドの全構文を以下に示します。
pg_standby [ option ... ] archivelocation nextwalfile xlogfilepath [ restartwalfile ]
restore_commandで使用すると、%fおよび%pマクロは、リストア/リカバリで必要となる実際のファイルとパスを提供するためのnextwalfileおよびxlogfilepathを指定しなければなりません。
通常%rマクロを使用してrestartwalfileが指定された場合、このファイルより論理的に前のすべてのWALファイルはarchivelocationから削除されます。 これはクラッシュからの再起動ができることを保持しつつ、保持する必要があるファイルの数を最小化します。 archivelocationがスタンバイサーバで一時使用用の領域である場合、このパラメータの使用は適切です。 しかし、archivelocationが長期間のWAL保管を目的とした領域である場合は、不適切です。
pg_standbyは、archivelocationがサーバを所有するユーザから読み取り可能なディレクトリであることを前提とします。 restartwalfile（または-k）が指定される場合、archivelocationディレクトリは書き込み可能である必要もあります。
表 F-26. pg_standbyオプション
| オプション | デフォルト | 説明 |
|---|---|---|
| -c | yes | アーカイブからWALファイルをリストアするために cpまたはcopyコマンドを使用します。 |
| -d | no | stderrに多くのデバッグ用のログ出力を出力します。 |
| -k numfiles | 0 | ここで指定した数より多くの、現在のWALファイルより前のWALファイルをアーカイブ内に保持しないようにarchivelocationからファイルを削除します。 ゼロ（デフォルト）はarchivelocationからファイルをまったく削除しないことを意味します。 このパラメータはrestartwalfileが指定された場合、このパラメータは警告なく無視されます。 アーカイブ内の正確な切り捨て点を決定する際にこの指定方法の方が正確だからです。 PostgreSQL 8.3時点で、このパラメータの使用は廃止予定です。 restartwalfileパラメータの指定の方が安全、かつ効率的だからです。 あまりにも小さな値を設定すると、スタンバイサーバの再起動に必要とするファイルも削除されてしまう可能性があります。 一方であまりに大きな値を設定することはアーカイブ領域を無駄に消費します。 |
| -l | no | アーカイブからWALファイルをリストアするためにlnコマンドを使用します。 リンクはコピーより効率的ですが、すべての状況でリンクが動作しませんので、コピーがデフォルトです。 Windowsでは、このオプションはファイルからファイルへのシンボリックリンクを提供するmklinkコマンドを使用します。 -lはVista以前のバージョンのWindowsでは動作しません。 |
| -r maxretries | 3 | コピーまたはリンクコマンドが失敗した場合の最大再試行回数を設定します。 失敗する度に、待ち時間が比例して増加するようにsleeptime * num_retries待機します。 このためデフォルトでは、スタンバイサーバに戻すことに失敗したと報告する前に、5秒、10秒、15秒待機することになります。 これはリカバリの終了、その結果としてスタンバイが完全な状態になったと解釈されます。 |
| -s sleeptime | 5 | リストアすべきWALがアーカイブ内で利用できるかどうかの判定試験の間の待機時間を秒単位で設定します（最大60）。 デフォルト設定は必ずしも推奨するものではありません。 項24.4を参考に検討してください。 |
| -t triggerfile | なし | トリガファイルを指定します。 このファイルが存在すると、次のWALファイルが利用できるかどうかによって、リカバリを終了させることができます。 同一システムに複数のサーバが存在する場合、たとえば/tmp/pgsql.trigger.5432などのように構造を持ったファイル名を使用して、どのサーバにトリガを送るかどうか混乱しないようにすることを推奨します。 |
| -w maxwaittime | 0 | リカバリが終了しスタンバイが有効になった後に、次のWALファイルを待機する最大秒数を設定します。 ゼロ（デフォルト）に設定することは永久に待機することを意味します。 デフォルトの設定は必ずしも推奨されません。 項24.4を参考にして検討してください。 |
注意: 開発および試験中を除きpg_standbyは対話式な使用を想定していませんので、--helpはサポートされません。
LinuxまたはUnixシステムでは以下のように使用できます。
archive_command = 'cp %p .../archive/%f' restore_command = 'pg_standby -l -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log'
ここでは、アーカイブディレクトリは物理的にスタンバイサーバ上にあります。 このため、archive_commandはNFS経由でそこにアクセスします。 しかしこのファイルは（lnの使用を有効にした）スタンバイではローカルです。 このため、以下のようになります。
アーカイブからWALファイルをリストアするために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'
archive_commandではバックスラッシュを二重にする必要があり、restore_commandでは必要がないことに注意してください。 これは以下のようになります。
アーカイブからWALファイルをリストアするためにcopyコマンドを使用します。
standby.logにデバッグ用の出力を書き出します。
次のWALファイルが利用可能になったかどうかの検査するまで5秒待機します。
C:\pgsql.trigger.5442というトリガファイルが出現した場合待機を止めます。
必要なくなったファイルをアーカイブディレクトリから削除します。
Windowsの例では、両方でcopyを使用しますので、両サーバまたは片方のサーバはネットワーク経由でアーカイブディレクトリにアクセスすることになります。
pg_standbyはPostgreSQL 8.2以降で動作するよう設計されました。
PostgreSQL 8.3は、保持する必要がある最後のファイルをpg_standbyに知らせるために設計された%rマクロを提供します。 PostgreSQL 8.2では、アーカイブの整理が必要な場合-kオプションを使用しなければなりません。 このオプションは8.3でも利用可能ですが、この使用は廃止予定です。
Simon Riggs <simon@2ndquadrant.com>