このバッチファイルでの処理概要は以下のようになります。下記にバッチファイルの具体的な記述例を記載します。設定は以上になります。本節ではWindows上に構築したPostgreSQLに対して、PCPコマンドが利用可能かどうかを検証します。サポートしているPCPコマンド及び、検証結果の概要は下表の通りになります。この内、pcp_watchdog_infoとpcp_recovery_nodeは今回の検証環境では実行できないため、検証の対象外とします。対応していないため)以下に具体的な実施例を示します。本検証環境ではPgpool-IIに3ノード認識させているので、コマンドの実行結果は「3」と表示されます。pcp_node_info¶pcp_node_infoは各ノード毎に実施します。pcp_proc_count¶Pgpool-IIのプロセスが表示されます。このコマンドによる表示結果はpsコマンドで表示されるPgpool-IIのプロセスIDと同じになります。接続中のPgpool-IIプロセスの情報を表示します。name,value,descriptionの順に表示します。pcp_detach_node¶Pgpool-IIからノードを切り離します。pcp_attach_node¶Pgpool-IIにノードを復帰させます。pcp_promote_node¶Pgpool-IIのノードをマスタに昇格させます。PostgreSQLの昇格は行われません。マスタになりますが、PostgreSQLのレプリケーションの状態は変わりません。pcp_stop_pgpool¶Pgpool-IIをシャットダウンします。サーバ各サーバ間のネットワークの3点になりますが、今回はWindows環境における障害検知・切り替えの動作検証を実施するため、Windows環境に関わる項番1のみ動作検証します。項番2,3につきましては、2013年WG3の成果物として公開していますので、そちらをご覧ください。サーバの障害が発生するケースとして、PostgreSQLプロセスがダウンするWindowsサーバ自体がダウンするDBクラスタを格納しているストレージが故障するサービス側のネットワークが切断するなどを挙げることができます。いずれのパターンもPgpool-IIからは定期的にバックエンドに接続を試みて、接続できなくなったら障害が発生したと判定しています。PostgreSQLサービスをシャットダウンして状況をシミュレーションします。0)がマスタとして、それ以外のノードはスレーブとして動作してかつ、各ノード間でストリーミングレプリケーションが行われている状態を初期状態とします。以後の項では、スレーブDBがダウンした場合(5.4.1)3台中1台目のマスタDBがダウンした場合(5.4.2)3台中2台目のマスタDBがダウンした場合(5.4.3)の3パターンの障害にについて、挙動と回復方法を検証します。スレーブDBがダウンした場合の障害検証¶スレーブDBに障害が発生した時の状況の概念図が下記になります。2に接続できない事を検知し、ステータスをdownに変更してサービスを続行します。以下に実際の挙動を記載します。2)がダウンした時のPgpool-IIのログは以下のようになりました。スレーブDBなので、ノードを切り離すだけで処理が終了します。結果は以下のようになりました。downとなっています。マスタである事に変わりありません。この時のレプリケーション状態は下記の通りでした。レプリケーションされていない状態となっています。復旧の大まかな流れは以下のようになります。これは本環境の構築時にスレーブDBを設定した時と同様に、pg_basebackupを実行することで実現します。pg_basebackupの実行の前に、古くなったDBクラスタディレクトリ「C:\PostgreSQL\10\data」を削除又はリネームします。削除が完了したら、下記のようにpg_basebackupを実行します。completedpg_basebackupが完了したら、生成された「C:\PostgreSQL\10\data」のパーミッションを変更します。個のファイルが正常に処理されました。個のファイルを処理できませんでしたpg_basebackupが終了したら、「C:\PostgreSQL\10\data」が新たに作成されます。存在している事もありますが、これらは削除します。DBサーバを実際に起動します。PostgreSQLの起動はこれまで通り、Windowsのサービス経由で起動します。発行し、レプリケーションの状態を確認します。rows)ノードの認識状況を下記のコマンドで確認します。rows)上記のように、3台ともstatusがupで、roleも期待した配置になっていれば復旧は完了です。3台中1台目のマスタDBがダウンした場合の障害検証¶マスタDBに障害が発生した時の状況の概念図が下記になります。パラメータに記載した処理を実行します。パラメータに記載した処理を行います。同期させ、同期後にPgpool-IIのセカンダリノードとして接続します。以下に実際の挙動を記載します。マスタに昇格するマスタDBがダウンした時のPgpool-IIのログは以下のようになりました。0のPostgreSQLを停止した時のログになります。新たなマスタDBに昇格している事が確認できます。実行されている事も確認できます。結果は以下のようになりました。downとなっています。マスタへプロモートしています。