これは、Ubuntu Online、Fedora Online、Windowsオンラインエミュレータ、MAC OSオンラインエミュレータなど、複数の無料オンラインワークステーションのいずれかを使用して、OnWorks無料ホスティングプロバイダーで実行できるコマンドpg_standbyです。
プログラム:
NAME
pg_standby - PostgreSQLウォームスタンバイサーバの作成をサポートします
SYNOPSIS
pg_スタンバイ [オプション...] アーカイブロケーション ネクストウォルファイル xlogファイルパス [再起動ファイル]
DESCRIPTION
pg_standbyは「ウォームスタンバイ」データベースサーバーの作成をサポートします。これは、
すぐに使えるプログラムと、特定のニーズに合わせたカスタマイズ可能なテンプレートもご用意しています。
変更。
pg_standbyは待機状態になるように設計されている 復元コマンド標準を変えるために必要な
アーカイブリカバリをウォームスタンバイ操作に移行します。その他の設定も必要です。
これらはすべて、メインサーバマニュアルに記載されています(セクション25.2「ログ配布」を参照)。
(ドキュメントの「スタンバイ サーバー」を参照)。
スタンバイサーバーがpg_standbyを使用するように設定するには、これをrecovery.confに追加します。
設定ファイル:
restore_command = 'pg_standby アーカイブディレクトリ %f %p %r'
コラボレー アーカイブディレクトリ WAL セグメント ファイルを復元するディレクトリです。
If 再起動ファイル 通常は%rマクロを使用して指定され、その後すべてのWALファイルが
このファイルの論理的前にあるファイルは削除されます アーカイブロケーションこれにより、
クラッシュリスタート機能を維持しながら、保持する必要があるファイルの数。
このパラメータは、 アーカイブロケーション 一時的な待機場所である
この特定のスタンバイサーバーですが、 時 アーカイブロケーション は、
長期 WAL アーカイブ領域。
pg_standbyは、 アーカイブロケーション サーバーを所有するユーザーが読み取り可能なディレクトリです。
If 再起動ファイル (または-k)が指定されている場合、 アーカイブロケーション ディレクトリは書き込み可能である必要があります
のためにペンを持つ時間も見つけています。
マスターサーバーが停止したときに「ウォームスタンバイ」データベースサーバーにフェイルオーバーする方法は2つあります。
失敗します:
スマートフェイルオーバー
スマートフェイルオーバーでは、利用可能なすべてのWALファイルを適用した後にサーバーが起動されます。
アーカイブ。これにより、スタンバイサーバーがダウンした場合でも、データ損失は発生しません。
遅れていますが、適用されていないWALがたくさんある場合は、
スタンバイサーバーが準備完了になります。スマートフェイルオーバーをトリガーするには、トリガーファイルを作成します。
「smart」という単語を含む文字列を作成するか、単に作成して空のままにしておきます。
高速フェイルオーバー
高速フェイルオーバーでは、サーバーは即座に起動されます。アーカイブ内のWALファイルは
まだ適用されていないものは無視され、それらのファイル内のすべてのトランザクション
失われます。高速フェイルオーバーをトリガーするには、トリガーファイルを作成し、fastという単語を記述します。
pg_standbyは、高速フェイルオーバーを自動的に実行するように設定することもできます。
定義された間隔内に新しい WAL ファイルが表示されない場合。
OPTIONS
pg_standby は次のコマンドライン引数を受け入れます。
-c
アーカイブからWALファイルを復元するには、cpまたはcopyコマンドを使用します。これはサポートされている唯一の方法です。
動作なのでこのオプションは役に立ちません。
-d
stderrに大量のデバッグログ出力を出力します。
-k
ファイルを削除する アーカイブロケーション 最大でこの数のWALファイルが
現在のファイルはアーカイブに保持されます。ゼロ(デフォルト)はファイルを削除しないことを意味します。
from アーカイブロケーションこのパラメータは、以下の場合には無視されます。 再起動ファイル is
指定された方法は、正しいものを決定するのにより正確であるため、
アーカイブのカットオフポイント。このパラメータの使用は 非推奨の PostgreSQL 8.3以降では、
より安全で効率的に 再起動ファイル パラメータ。小さすぎる設定
スタンバイの再起動に必要なファイルが削除される可能性があります
設定値が大きすぎると、サーバーのアーカイブ領域が無駄になります。
-r 最大再試行回数
コピー コマンドが失敗した場合に再試行する最大回数を設定します (デフォルトは 3)。
失敗するたびに、私たちは 睡眠時間 * num_retries 待ち時間が
徐々に増加します。デフォルトでは5秒、10秒、そして15秒待ちます
スタンバイサーバーに障害を報告する前に、次のように解釈されます。
リカバリが終了し、結果としてスタンバイが完全に起動します。
-s 睡眠時間
テストの間にスリープする秒数(最大60秒、デフォルトは5秒)を設定し、
復元するWALファイルがアーカイブ内にまだ存在していない。デフォルト設定では
必ずしも推奨されるものではありません。セクション25.2「ログシッピングスタンバイサーバ」を参照してください。
議論のためのドキュメント。
-t トリガーファイル
フェイルオーバーを発生させるトリガーファイルを指定します。
どのサーバーがアクセスされているかの混乱を避けるために、構造化されたファイル名を使用します。
同じシステム上に複数のサーバーが存在する場合にトリガーされます。例:
/tmp/pgsql.トリガー.5432。
-V
- バージョン
pg_standby のバージョンを印刷して終了します。
-w 最大待機時間
次のWALファイルを待つ最大秒数を設定します。その後、高速
フェイルオーバーが実行されます。0(デフォルト)に設定すると、永久に待機することを意味します。
デフォルト設定は必ずしも推奨されません。セクション25.2「ログ配布」を参照してください。
議論のためにドキュメントの「スタンバイ サーバー」を参照してください。
-?
- 助けて
pg_standby のコマンドライン引数に関するヘルプを表示して終了します。
注意事項
pg_standby は PostgreSQL 8.2 以降で動作するように設計されています。
PostgreSQL 8.3では%rマクロが提供されており、これはpg_standbyに最後の
保存する必要があるファイル。PostgreSQL 8.2では、アーカイブのクリーンアップを実行する場合は-kオプションを使用する必要があります。
必須です。このオプションは8.3でも利用可能ですが、使用は非推奨です。
PostgreSQL 8.4では、 リカバリ終了コマンド オプション。このオプションがなければ、
トリガーファイルは危険な場合があります。
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'
リカバリ終了コマンド = 'rm -f /tmp/pgsql.trigger.5442'
アーカイブディレクトリはスタンバイサーバー上に物理的に配置されているため、
アーカイブコマンド NFS経由でアクセスしているが、ファイルはスタンバイのローカルにある
(lnの使用を有効にする)。これにより、次のことが実現します。
· スタンバイログにデバッグ出力を生成する
· 次の WAL ファイルの可用性をチェックする間に 2 秒間スリープします
/tmp/pgsql.trigger.5442というトリガーファイルが現れたときだけ待機を停止し、
内容に応じてフェイルオーバーを実行する
· リカバリが終了したらトリガーファイルを削除する
・アーカイブディレクトリから不要になったファイルを削除します
Windows では、次のように使用できます。
archive_command = '%p ...\\archive\\%f をコピー'
restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log'
リカバリ終了コマンド = 'C:\pgsql.trigger.5442 を削除'
バックスラッシュは二重にする必要があることに注意してください アーカイブコマンド、 だけど 会場は
復元コマンド or リカバリ終了コマンドこれにより、次のようになります。
· コピーコマンドを使用してアーカイブからWALファイルを復元する
· スタンバイログにデバッグ出力を生成する
· 次の WAL ファイルの可用性をチェックする間に 5 秒間スリープします
· C:\pgsql.trigger.5442というトリガーファイルが現れたときだけ待機を停止し、
内容に応じてフェイルオーバーを実行する
· リカバリが終了したらトリガーファイルを削除する
・アーカイブディレクトリから不要になったファイルを削除します
Windowsのコピーコマンドは、ファイルが完全にコピーされる前に最終的なファイルサイズを設定します。
これは通常pg_standbyを混乱させるため、pg_standbyはsleeptime秒待機します。
適切なファイルサイズが判明したら、GNUWin32のcpはファイルサイズを設定する。
コピーが完了しました。
Windowsの例では両端でコピーを使用しているため、どちらかのサーバーまたは両方のサーバーが
ネットワーク経由でアーカイブ ディレクトリにアクセスします。
onworks.net サービスを使用して pg_standby をオンラインで使用する