Enterprise Postgres 15 クラスタ運用ガイド(データベース多重化編)

2.5.3 スタンバイサーバのMirroring Controllerの起動

スタンバイサーバのMirroring Controllerの起動について説明します。

裁定サーバを利用して自動縮退を行う運用では、事前に裁定サーバでMirroring Controller裁定プロセスを起動してください。

1. スタンバイサーバのMirroring Controllerは、プライマリサーバのMirroring Controllerのプロセスが起動していることを確認してから、起動します。

   自動切り替え/切り離しを有効化する場合

   インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで実行します。

   例)

   $ mc_ctl start -M /mcdir/inst1

   自動切り替え/切り離しを有効化しない場合

   インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで-Fオプションを指定して実行します。

   例)

   $ mc_ctl start -M /mcdir/inst1 -F

2. Mirroring Controllerプロセスの状態を確認します。

   インスタンス管理者ユーザーでmc_ctlコマンドをstatusモードで実行します。“mirroring status”が切り替え可能状態(switchable)になっていることを確認してください。

   例)

   $ mc_ctl status -M /mcdir/inst1

注意

• 裁定サーバを利用して自動縮退を行う運用の場合、データベースサーバが裁定サーバに接続する時間が加算されるため、利用しない運用に比べて、Mirroring Controllerの起動時間が長くかかる場合があります。

• 裁定サーバで設定したOS/サーバの生死監視のパラメータが、Mirroring ControllerのOS/サーバの生死監視のパラメータより大きい値の場合、Mirroring Controllerの起動に失敗することがあります。その場合、メッセージ通知の内容を確認し、裁定サーバまたはMirroring ControllerのOS/サーバの生死監視のパラメータを見直してください。

• 自動切り替え/切り離しを有効化してMirroring Controllerを起動した場合であっても、サーバ識別子.confファイルのheartbeat_error_actionの設定がmessageの場合、OS/サーバの生死監視での異常検出時は、切り替え/切り離しは自動で動作せず、メッセージ通知のみ行われます。

• セットアップ直後に、スタンバイサーバを誤ってプライマリサーバとして起動した場合や、切り替えが行われた後の旧プライマリサーバを復旧せずに、誤ってプライマリサーバとして起動した場合、通常はMirroring Controllerの起動が失敗しますが、万が一、管理用ネットワークが切断されていると起動を失敗させることができず、両サーバがプライマリサーバとなってしまう可能性があります。そのため、Mirroring Controllerの起動は、管理用ネットワークが接続していることを確認してから行ってください。

ポイント

• 裁定サーバを利用して自動縮退を行う運用では、事前に裁定サーバでMirroring Controller裁定プロセスを起動していない場合、mc_ctlコマンドが失敗します。ただし、事前にMirroring Controller裁定プロセスを起動できない場合であっても、mc_ctlコマンドに--async-connect-arbiterオプションを指定することで、Mirroring Controllerプロセスを起動することができます。

• 自動切り替え/切り離しはMirroring Controllerが起動したあとに、mc_ctlコマンドのenable-failoverモード、または、disable-failoverモードを使用することにより自動切り替え/切り離しを有効、または無効にすることが可能です。