| Pgpool-II 4.4devel 文書 | |||
|---|---|---|---|
| 前のページ | 上に戻る | 第 5章サーバの設定 | 次のページ |
Pgpool-II はサービスを止めることなくデータベースノードを同期させ、ノードを復帰させることができます。 この機能は「オンラインリカバリ」と呼ばれます。 オンラインリカバリはpcp_recovery_nodeコマンドで実行できます。
オンラインリカバリを実施するためには、リカバリ対象のノードはPgpool-IIから切り離された状態になっていなければなりません。 このことは、そのノードが、pcp_detach_nodeで手動で切り離された状態にあるか、フェイルオーバの結果、Pgpool-IIにより自動的に切り離された状態にあるかのいずれかでなければならないことを意味します。
新しいPostgreSQLサーバを動的に追加したい場合には、backend_hostnameおよび関連パラメータを追加した後にpgpool.confを再読み込みします。 これにより新しいサーバが切り離された状態のバックエンドノードとしてPgpool-IIに登録されるので、その後pcp_recovery_nodeコマンドを実行しサーバを追加できます。
注意: オンラインリカバリ実行のためには、対象となるPostgreSQLサーバは稼働していてはいけません。 対象のPostgreSQLがすでに動作中であれば、オンラインリカバリを開始する前にシャットダウンしておいてください。
オンラインリカバリは2段階に分けて実施されます。 第1段階は「ファーストステージ」、第2段階は「セカンドステージ」と呼ばれます。 native_replication_modeあるいはsnapshot_isolation_modeの時のみセカンドステージが必要です。 ストリーミングレプリケーションモードを含むその他のモードでは、セカンドステージは実施されず、recovery_2nd_stage_command用のスクリプトを用意する必要はありません。 つまり、そのエントリを空文字にしておいても問題ありません。
ファーストステージでは、PostgreSQLのpg_basebackupコマンドなどを利用してメイン(プライマリ)ノードのバックアップコピーからレプリカ(スタンバイ)ノードを作ります。 ファーストステージ中に更新されたデータはPostgreSQLのトランザクションログに記録されます。
セカンドステージでは、リカバリ対象のレプリカノードを起動します。 この時にトランザクションログが再生され、このレプリカノードは完全にメインノードと同期します。
それぞれのステージ用にスクリプトを用意する必要があります。 完全なサンプルスクリプトが/etc/pgpool-II/recovery_1st_stage.sampleおよび/etc/pgpool-II/recovery_2nd_stage.sampleに用意されています。 これらのスクリプトを使ったインストール例は項8.2.6.8にあります。
ファーストステージではデータの更新や読み取りができますが、セカンドステージではクライアントからの接続は許されていません。
オンラインリカバリではPgpool-IIは以下の手順を実施します。
CHECKPOINT.
オンラインリカバリのファーストステージ。
全てのクライアント接続が切断されるまで待機（native_replication_modeあるいはsnapshot_isolation_modeのみ）。
CHECKPOINT.
オンラインリカバリのセカンドステージ（native_replication_modeあるいはsnapshot_isolation_modeのみ）。
postmasterの起動（pgpool_remote_startの実施）
pgpool_remote_startは、リカバリ対象のPostgreSQLを起動するためのスクリプトです。 pgpool_remote_startは次の2つの引数を受けとります。
リカバリされるバックエンドノードのホスト名
リカバリされるバックエンドノードのデータベースクラスタへのパス
スクリプトの例は項8.2.6.8にあります。
注意: スクリプトのパスおよびファイル名は固定されており、メイン(プライマリ)ノード上で$PGDATA/pgpool_remote_startが実行されます。
ノードの復帰
注意: native_replication_modeあるいはsnapshot_isolation_modeでのオンラインリカバリには制限事項があります。 Pgpool-IIが複数のホストにインストールされている場合、Pgpool-IIはオンラインリカバリの2ndステージの間全てのクライアントを止める必要があるため、オンラインリカバリは正しく動作しません。 複数のPgpool-IIホストがある場合、そのうちの１台のみがオンラインリカバコマンドを受け取り、クライアントからの接続をブロックします。
オンラインリカバリを行うためのPostgreSQLユーザ名です。
オンラインリカバリで実行されるpgpool_recovery関数はPostgreSQLのスーパーユーザ権限が必要なため、recovery_userにスーパーユーザを指定しなければなりません。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
オンラインリカバリを行うための PostgreSQL ユーザパスワードです。
recovery_passwordが空のままの場合、 Pgpool-IIは空のパスワードを使用する前にまずpool_passwdファイルからrecovery_userのパスワードを取得できるか試みます。
recovery_passwordにAES256-CBCで暗号化されたパスワードも指定することができます。 AESで暗号化されたパスワードを指定するためには、パスワード文字列は暗号化（aes-256-cbcアルゴリズムを使用）およびbase64でエンコードした後、AESを接頭辞として付けなければいけません。
暗号化されていないクリアテキストパスワードを指定するためには、TEXTをパスワード文字列の前に付けます。 例えば、パスワードとしてmypassを設定したい場合、パスワードフィールドにTEXTmypassと指定すべきです。 有効な接頭辞がない場合、Pgpool-IIは平文のパスワードとして文字列を見なします。
正しくフォーマットされたAES暗号化パスワードをpg_encコマンドを使用して作成することもできます。
注意: Pgpool-IIは暗号化されたパスワードを使うために起動時に有効な復号鍵を要求します。 Pgpool-IIに復号鍵を提供する方法の詳細は項6.4.2を参照してください。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
オンラインリカバリのファーストステージでメイン（プライマリ）ノードで実行されるコマンドを指定します。 コマンドファイルはセキュリティ上の観点からデータベースクラスタ内に配置される必要があります。 例えば、recovery_1st_stage_command = 'sync-command'となっている場合、Pgpool-IIはコマンドスクリプトを$PGDATAディレクトリの中で探し、$PGDATA/sync-commandを起動しようとします。
recovery_1st_stage_commandは次の7つの引数を受けとります。
メイン（プライマリ）ノードのデータベースクラスタへのパス
リカバリされるバックエンドノードのホスト名
リカバリされるノードのデータベースクラスタへのパス
メイン（プライマリ）ノードのポート番号（Pgpool-II 3.4以降）
リカバリされるノードの番号（Pgpool-II 4.0以降）
リカバリされるノードのポート番号（Pgpool-II 4.1以降）
main (primary)ノードのホスト名（Pgpool-II 4.3以降)
以前はmain (primary)ノードのホスト名はhostnameコマンドを使って取得されていました。 スクリプトがmain (primary)ノードで実行されるため、これはほとんどの場合問題になりません。 しかし、ある種のシステムでは、hostnameコマンドを使って取得したホスト名とbackend_hostname設定パラメータが一致しません。 これはdetach_false_primaryで問題になります。 なぜなら、recovery_1st_stage_commandが生成するprimary_conninfo のhostパラメータを使ってプライマリとスタンバイの接続性を確認するからです。 ですから、recovery_1st_stage_commandにおいては、hostnameコマンドではなく、このパラメータを使ってプライマリノードのホスト名を得るようにすることを強くおすすめします。
注意: recovery_1st_stage_commandの実行中はPgpool-IIは接続やクエリを受け付けており、データの参照や更新を行うことができます。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
オンラインリカバリのセカンドステージでメインノードで実行されるコマンドを指定します。 これはnative_replication_modeあるいはsnapshot_isolation_mode時のみ必要であるため、他のモードではコマンドファイルを用意する必要はありません。 コマンドファイルはセキュリティ上の観点からデータベースクラスタ内に配置される必要があります。 例えば、recovery_2nd_stage_command = 'sync-command'となっている場合、Pgpool-IIはコマンドスクリプトを$PGDATAディレクトリの中で探し、$PGDATA/sync-commandを起動しようとします。
recovery_2nd_stage_commandは次の7つの引数を受けとります。
メイン（プライマリ）ノードのデータベースクラスタへのパス
リカバリされるバックエンドノードのホスト名
リカバリされるノードのデータベースクラスタへのパス
メイン（プライマリ）ノードのポート番号（Pgpool-II 3.4以降）
リカバリされるノードの番号（Pgpool-II 4.0以降）
リカバリされるノードのポート番号（Pgpool-II 4.1以降）
main (primary)ノードのホスト名（Pgpool-II 4.3以降)
注意: recovery_2nd_stage_commandの実行中は、Pgpool-IIはクライアントからの接続およびクエリを受け付けません。 また、コマンドを実行する前に既存のクライアントが接続を閉じるのを待ちます。 そのため、長時間接続したままのクライアントがいる場合、recovery_2nd_stage_commandは実行されない可能性があります。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
時間内にオンラインリカバリが完了しなかった場合に、これをキャンセルするためのタイムアウトを秒単位で指定します。 Pgpool-IIは、オンラインリカバリのセカンドステージの間は接続を受け付けないので、このパラメータはオンラインリカバリの最中のサーバがダウンした時にオンラインリカバリをキャンセルするのに使えます。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。
オンラインリカバリの最中で、クライアントが前回のクエリからアイドル状態のままでいるときに、それを切断するまでの時間を秒単位で指定します。 client_idle_limit_in_recoveryはclient_idle_limitと似ていますが、オンラインリカバリのセカンドステージでのみ効果を持ちます。
これは、だらしないクライアントやPgpool-IIの間のTCP/IPコネクションの不調（例えばケーブルの切断など）によって、Pgpool-IIのリカバリが邪魔されるのを防止するのに役立ちます。
注意: client_idle_limit_in_recoveryは、recovery_timeoutよりも小さな値でなければなりません。 さもないと、recovery_timeoutのタイムアウトが先に起こり、オンラインリカバリを実行中に以下のエラーとなります。
ERROR: node recovery failed, waiting connection closed in the other pgpools timeout
-1に設定すると、オンラインリカバリのセカンドステージが始まると全てのクライアントは直ちに切断されます。 デフォルト値は0で、この機能は無効です。
このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。 現在のセッションでのパラメータ値は、PGPOOL SETコマンドで変更することもできます。