10. フェールオーバーのシナリオ
この展開で考えられるフェールオーバーのシナリオおよびそれらに対して予期される対応。
シナリオ 1: PostgreSQL マスターノードが失敗
node0 (現在の PostgreSQL マスターノード) が失敗した場合、以下の処理が自動的に行われます。
• Pgpool が /etc/pgpool-II/failover.sh の実行を開始します。
• PostgreSQL node1 が新規マスターとして選択されます。
• Pgpool-II マスターが node1 にリモートにログインしてこれをマスターとしてプロモートします。
予期される手動操作
システム管理者が実行する操作:
• node0 でログをレビューしてサーバーの正常性を判別します。
• 必要に応じてサーバーを修復します。
• 正常であると判断した場合、以下の操作を行います。
◦ node0 で、start_replication スクリプトを実行して node0 が node2 に従うようにします (この例では IP アドレス 10.91.9.41 が node2 の IP です)。
/db/bin/start_replication.sh 10.91.9.41
◦ node0 で PostgreSQL サービスを開始します
sudo systemctl start postgresql-10.x
◦ PCP コマンドを使用して node0 を再び正常ステータスに追加します。
pcp_attach_node -h /var/run/pgpoolpcp -n 0
シナリオ 2: PostgreSQL の 1 つ目のスタンバイノードが失敗
node1 (現在の PostgreSQL プライマリスタンバイノード) が失敗した場合、以下の処理が自動的に行われます。
• Pgpool が '/etcpgpool-II/failover.sh' の実行を開始します。
• PostgreSQL node2 がマスターノード (この例では node0) のプライマリスタンバイノードとして選択されます。
• Pgpool が node2 にリモートにログインしてそのターゲットを node0 に変更します。
• node2 が node0 のスタンバイノードになりました。
予期される手動操作
システム管理者が実行する操作:
• node1 でログをレビューしてサーバーの正常性を判別します。
• 必要に応じてサーバーを修復します。
• 正常であると判断した場合、以下の操作を行います。
◦ node1 で、start_replication スクリプトを実行して node1 が node2 に従うようにします (この例では IP アドレス 10.91.9.41 が node2 の IP です)。
/db/bin/start_replication.sh 10.91.9.41
◦ node1 で PostgreSQL サービスを開始します
sudo systemctl start postgresql-10.x
◦ PCP コマンドを使用して node1 を再び正常ステータスに追加します。
pcp_attach_node -h /var/run/pgpoolpcp -n 1
シナリオ 3: PostgreSQL の 2 つ目のスタンバイノードが失敗
node2 (現在の PostgreSQL セカンダリスタンバイノード) が失敗した場合、以下の処理が自動的に行われます。
• Pgpool が '/etcpgpool-II/failover.sh' の実行を開始します。
• node2 は現在のマスターとスタンバイの動作に影響しないので、これ以上の処理は行われません。
予期される手動操作
システム管理者が実行する操作:
• node2 でログをレビューしてサーバーの正常性を判別します。
• 必要に応じてサーバーを修復します。
• 正常であると判断した場合、以下の操作を行います。
◦ node2 で、start_replication スクリプトを実行して node2 を node1 と再同期化します (この例では IP アドレス 10.91.9.24 が node1 の IP です)。
/db/bin/start_replication.sh 10.91.9.24
◦ node2 で PostgreSQL サービスを開始します
sudo systemctl start postgresql-10.x
◦ PCP コマンドを使用して node2 を再び正常ステータスに追加します。
pcp_attach_node -h /var/run/pgpoolpcp -n 2