pg_standby

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 付録 F. 追加で提供されるモジュール | 早送り | 次のページ

# F.26. pg_standby

pg_standbyは"ウォームスタンバイ"データベースサーバの作成をサポートします。 これは、特定の変更が必要となるカスタマイズ可能なテンプレートを持つ、製品レベルのプログラムとなるよう設計されています。

pg_standbyは、標準のアーカイブリカバリからウォームスタンバイに切り替わるために必要とされる`restore_command`を待機するものとして設計されています。 他の設定も必要ですが、主サーバマニュアルにすべての情報が説明されています（項24.4を参照してください）。

pg_standbyの機能は以下のとおりです。

- C言語で作成されています。 移植性に優れ、インストールが簡単です。

- ソースの変更が簡単です。 特に独自の必要性によって変更すべき部分が限定されています。

- LinuxとWindowsで試験済みです。

## F.26.1. 使用方法

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`ディレクトリは書き込み可能である必要もあります。

マスタサーバが失敗した時の"ウォームスタンバイ"データベースサーバへフェイルオーバーする方法は以下の2つがあります。

スマートフェイルオーバー

  スマートフェイルオーバーは、アーカイブで利用可能なすべてのWALファイルを適用した後に、サーバが準備完了となります。 待機サーバが遅れてもデータロスとなることは全くありませんが、多くの適用されていないWALがある場合、待機サーバの準備には長時間かかるかもしれません。 スマートフェイルオーバーのトリガとなるためには、単語`smart`を含むトリガファイルを作成するか、単に空のファイルを作成してください。

ファストフェイルオーバー

  ファストフェイルオーバーでは、サーバはすぐに準備完了となります。 アーカイブでまだ適用されていないWALファイルは無視され、そして、それらのファイルに書かれていたすべてのトランザクションは失われます。 ファストフェイルオーバーのトリガとなるためには、トリガファイルを作成し、単語`fast`をそこに書いてください。 また、指定された間隔以内に新しいWALファイルが出現しないのであれば、自動的にファストフェイルオーバーを実行するようにpg_standbyを設定することができます。

表 F-23. pg_standbyオプション

オプション | デフォルト | 説明
--- | --- | ---
`-c` | yes | アーカイブからWALファイルをリストアするために `cp`または`copy`コマンドを使用します。
`-d` | no | `stderr`に多くのデバッグ用のログ出力を出力します。
`-k` `numfiles` | 0 | ここで指定した数より多くの、現在のWALファイルより前のWALファイルをアーカイブ内に保持しないように`archivelocation`からファイルを削除します。 ゼロ（デフォルト）は`archivelocation`からファイルをまったく削除しないことを意味します。 このパラメータは`restartwalfile`が指定された場合、このパラメータは警告なく無視されます。 アーカイブ内の正確な切り捨て点を決定する際にこの指定方法の方が正確だからです。 PostgreSQL 8.3時点で、このパラメータの使用は廃止予定です。 `restartwalfile`パラメータの指定の方が安全、かつ効率的だからです。 あまりにも小さな値を設定すると、待機サーバの再起動に必要とするファイルも削除されてしまう可能性があります。 一方であまりに大きな値を設定することはアーカイブ領域を無駄に消費します。
`-r` `maxretries` | 3 | コピーが失敗した場合の最大再試行回数を設定します。 失敗する度に、待ち時間が比例して増加するように`sleeptime` * `num_retries`間待機します。 このためデフォルトでは、待機サーバに戻すことに失敗したと報告する前に、5秒、10秒、15秒待機することになります。 これはリカバリの終了、その結果としてスタンバイがすっかり成功したと解釈されます。
`-s` `sleeptime` | 5 | リストアすべきWALがアーカイブ内で利用できるかどうかの判定試験の間の待機時間を秒単位で設定します（最大60秒まで）。 デフォルト設定は必ずしも推奨するものではありません。 項24.4を参考に検討してください。
`-t` `triggerfile` | なし | その存在がフェイルオーバーを発生させるきっかけとなるトリガファイルを指定します。 同一システムに複数のサーバが存在する場合、たとえば`/tmp/pgsql.trigger.5432`などのように構造を持ったファイル名を使用して、どのサーバにトリガを送るか混乱しないようにすることを推奨します。
`-w` `maxwaittime` | 0 | ファストフェイルオーバー実行後に、次のWALファイルを待機する最大秒数を設定します。 ゼロ（デフォルト）に設定することは永久に待機することを意味します。 デフォルトの設定は必ずしも推奨されません。 項24.4を参考にして検討してください。

## F.26.2. 例

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`では必要がないことに注意してください。 これは以下のようになります。

- アーカイブからWALファイルをリストアするために`copy`コマンドを使用します。

- `standby.log`にデバッグ用の出力を書き出します。

- 次のWALファイルが利用可能になったかどうか検査するまで5秒待機します。

- `C:\pgsql.trigger.5442`というトリガファイルが出現すると待機を中止し、その内容に従ってフェイルオーバーを実行します。

- 復旧が終了した時点で、トリガファイルを削除します。

- 必要なくなったファイルをアーカイブディレクトリから削除します。

Windowsの`copy`コマンドは、ファイルが完全にコピーされる前に、最終的なファイルサイズを設定します。これは通常pg_standbyを間違えさせます。。したがって、pg_standbyは適切なファイルサイズを見てから、いったん`sleeptime`秒待ちます。GNUWin32の`cp`は、ファイルコピーが完了した後にだけ、ファイルサイズを設定します。

Windowsの例を使うと、両方で`copy`を使用しますので、両サーバまたは片方のサーバはネットワーク経由でアーカイブディレクトリにアクセスすることになります。

## F.26.3. サポートするサーバのバージョン

pg_standbyはPostgreSQL 8.2以降で動作するよう設計されています。

PostgreSQL 8.3は、保持する必要がある最後のファイルをpg_standbyに知らせるために設計された`%r`マクロを提供します。 PostgreSQL 8.2では、アーカイブの整理が必要な場合`-k`オプションを使用しなければなりません。 このオプションは8.3でもまだ利用可能ですが、この使用は廃止予定です。

PostgreSQL 8.4は、`recovery_end_command`を提供します。 このオプションがないと、残ったトリガファイルは危険である場合があります。

## F.26.4. 作者

Simon Riggs `<simon@2ndquadrant.com>`

前のページ | ホーム | 次のページ
pgrowlocks | 上に戻る | pg_stat_statements