Using Failover Manager ====================== フェールオーバーマネージャーは、1つ以上のスタンバイサーバーを含むクラスターの監視とフェールオーバーのサポートを提供します。リソースの需要の増加または縮小に応じて、クラスターからノードを追加または削除できます。 プライマリノードが再起動すると、フェールオーバーマネージャーは、プライマリノードでデータベースがダウンしていることを検出し、スタンバイノードをプライマリの役割に昇格させる場合があります。これが発生した場合、リブートされたプライマリノードのFailover Managerエージェントは、\ ``recovery.conf`` ファイルを書き込んで、Postgresがセカンダリプライマリとして起動しないことを確認しようとします。したがって、データベースサーバーを起動する前にFailover Managerエージェントを起動する必要があります。エージェントはアイドルモードで起動し、クラスター内に既にプライマリが存在するかどうかを確認します。プライマリノードがある場合、エージェントは\ ``recovery.conf`` または\ ``standby.signal`` ファイルが存在することを確認するか、必要に応じて\ ``recovery.conf`` を作成して、データベースがセカンドプライマリとして起動しないようにします。 フェールオーバーマネージャークラスターの管理 -------------------------------------------- フェールオーバーマネージャークラスターは、一度構成すると、定期的なメンテナンスは必要ありません。ただし、フェールオーバーマネージャークラスターで時折必要になる管理タスクを実行できます。 デフォルトでは、 :ref:`some of the efm commands ` はefmまたはOSスーパーユーザーが呼び出す必要があります。管理者は、ユーザーをefmグループに追加することにより、ユーザーがこれらのコマンドを呼び出すことを選択的に許可できます。コマンドは次のとおりです。 - :ref:`efm allow-node ` - :ref:`efm disallow-node ` - :ref:`efm promote ` - :ref:`efm remote-members ` - :ref:`efm resume ` - :ref:`efm set-priority ` - :ref:`efm stop-cluster ` - :ref:`efm upgrade-conf ` フェールオーバーマネージャークラスターの開始 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ フェールオーバーマネージャークラスターのノードは、任意の順序で起動できます。 RHEL/Rocky Linux/AlmaLinux 8.x以降でFailover Managerクラスターを起動するには、スーパーユーザー権限を引き受けて、コマンドを呼び出します。 ``systemctl start edb-efm-5.`` .. Note:: バージョン4.xを使用し、エージェントが起動に失敗した場合、詳細については、起動ログ `/var/log/efm-4./startup-efm.log` を参照してください。それ以外の場合は、サービスステータスを参照します。 ``systemctl status edb-efm-5.`` ノードのクラスタープロパティファイルで\ ``is.witness`` が\ ``true`` が指定されている場合 、ノードは監視ノードとして起動します。 ノードが専用の監視ノードでない場合、フェールオーバーマネージャーはローカルデータベースに接続し、\ ``pg_is_in_recovery()`` ファンクションを呼び出します。サーバーが\ ``false`` に応答した場合、エージェントはノードがプライマリノードであると想定し、必要に応じて仮想IPアドレスをノードに割り当てます。サーバーが\ ``true`` に応答した場合、Failover Managerエージェントはノードがスタンバイサーバーであると想定します。サーバーが応答しない場合、エージェントはアイドル状態で起動します。 クラスターに参加した後、Failover Managerエージェントは、指定されたデータベース資格情報を確認して、クラスター内のすべてのデータベースに接続できることを確認します。エージェントが接続できない場合、エージェントはシャットダウンします。 新しいプライマリまたはスタンバイノードがクラスターに参加する場合、既存のすべてのノードも、新しいノードのデータベースに接続できることを確認します。 .. Note:: `tmpfs` 一時ファイルシステムで`/var/lock` または`/var/run` を実行している場合、フェールオーバーマネージャーのsystemdサービスファイルが`systemd-tmpfiles-setup.service` に依存していることを確認します。 クラスターへのノードの追加 ^^^^^^^^^^^^^^^^^^^^^^^^^^ ノードはフェールオーバーマネージャークラスターにいつでも追加できます。クラスターにノードを追加するときは、クラスターを変更して新しいノードを許可し、新しいノードにクラスターを見つける方法を指示する必要があります。 1. ``auto.allow.hosts`` が\ ``true`` に設定されていない限り、 ``efm allow-node`` コマンドを使用して、新しいノードのアドレスをFailover Managerの許可ノードホストリストに追加します。コマンドを呼び出すときに、新しいノードのクラスター名とアドレスを指定します。 ``efm allow-node
`` ``efm allow-node`` コマンドの使用またはフェールオーバーマネージャーサービスの制御の詳細については、 :ref:`efm allow-node ` を参照してください。 新しいノードにFailover Managerエージェントをインストールし、クラスタープロパティファイルを構成します。プロパティファイルの変更の詳細については、 :ref:`The cluster properties file ` を参照してください。 2. 新しいノードでクラスターメンバーファイルを構成し、メンバーシップコーディネーターのエントリーを追加します。クラスターメンバーファイルの変更の詳細については、 :ref:`The cluster members file ` を参照してください。 3. 新しいノードでスーパーユーザー権限を想定し、Failover Managerエージェントを起動します。 RHEL/Rocky Linux/AlmaLinux 8.x以降でFailover Managerクラスターを起動するには、次のコマンドを呼び出します。 ``systemctl start edb-efm-5.`` 新しいノードがクラスターに参加すると、フェールオーバーマネージャーは\ ``user.email`` プロパティで指定された管理者の電子メールに通知を送信し、指定された通知スクリプトを呼び出します。 .. Note:: 現在のノードの有用なスタンバイになるには、ノードはPostgreSQLストリーミングレプリケーションシナリオでスタンバイである必要があります。 スタンバイの優先度の変更 ^^^^^^^^^^^^^^^^^^^^^^^^ フェールオーバーマネージャークラスターに複数のスタンバイサーバーが含まれる場合、 ``efm set-priority`` コマンドを使用して、スタンバイノードのプロモーション優先度に影響を与えることができます。フェールオーバーマネージャークラスターの既存のメンバーでコマンドを呼び出し、メンバーのIPアドレスの後に優先度の値を指定します。 たとえば、次のコマンドは、 ``10.0.1.9`` を監視している\ ``acctg`` クラスターメンバーがプライマリスタンバイ\ ``(1)`` であることをフェールオーバーマネージャーに指示します。 .. code:: shell efm set-priority acctg 10.0.1.9 1 スタンバイの優先順位を\ ``0`` に設定して、スタンバイをプロモーション不可にすることができます。スタンバイの優先度を\ ``0`` より大きい値に設定すると、プロパティ値\ ``promotable=false`` がオーバーライドされます。 たとえば、ノード\ ``10.0.1.10`` 上のプロパティファイルが\ ``promotable=false`` の設定を含み、\ ``efm set-priority`` を使用して\ ``10.0.1.10`` の昇格プライオリティをフェールオーバーの際に使用されるスタンバイに設定している場合。 ``efm set-priority`` コマンドで指定された値は、プロパティファイルの値をオーバーライドします。 .. code:: shell efm set-priority acctg 10.0.1.10 1 フェールオーバーが発生すると、フェールオーバーマネージャーは最初にPostgresストリーミングレプリケーションから情報を取得して、どのスタンバイノードに最新のデータがあることを確認し、データ損失の可能性が最も低いノードをプロモートします。 2つのスタンバイノードに同等の最新データが含まれている場合、 :ref:`use.replay.tiebreaker ` が\ ``true`` に設定されていない限り、ユーザー指定の優先度値が高いノードがプライマリに昇格します。スタンバイノードの優先度値を確認するには、次のコマンドを使用します。 ``efm cluster-status `` .. Note:: 新しいプライマリが昇格すると、ノードの昇格優先度が変更されます。 ``efm set-priority`` コマンドを使用してスタンバイがプロモーション可能かどうかを変更した場合、プロモーションまたはクラスターの分割と再参加を介して、スタンバイのプロパティファイルの値にリセットされる場合があります。エージェントが再起動すると、プロモーション可能ステータスはプロパティファイルの値に戻ります。 フェールオーバーマネージャーノードの昇格 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ フェールオーバーマネージャークラスターの任意のノードで\ ``efm promote`` を呼び出して、スタンバイデータベースのプライマリデータベースへの手動プロモーションを開始できます。 データベースクラスターのメンテナンス時間帯にのみ手動プロモーションを実行します。使用可能な最新のスタンバイデータベースがない場合、続行する前にプロンプトが表示されます。手動プロモーションを開始するには、efmまたはOSスーパーユーザーのIDを引き継ぎ、次のコマンドを呼び出します。 ``efm promote [-switchover] [-sourcenode
] [-quiet] [-noscripts]`` そこで ```` は、フェールオーバーマネージャークラスターの名前です。 ``–switchover`` オプションを含めて、元のプライマリをスタンバイとして再構成します。 ``–switchover`` キーワードを含める場合、クラスターにはプライマリノードと少なくとも1つのスタンバイを含める必要があり、ノードは同期している必要があります。 ``–sourcenode`` キーワードを含めて、リカバリ設定をプライマリにコピーするノードを指定します。 スイッチオーバー中の通知を抑制するには、 ``-quiet`` キーワードを含めます。 ``-noscripts`` キーワードを含めて、フェンシングおよびポストプロモーションスクリプトを呼び出さないようにフェールオーバーマネージャーに指示します。 スイッチオーバー中に - ``primary_conninfo`` および\ ``restore_command`` パラメーターは、既存のスタンバイからプライマリノードにコピーされ、メモリに保存されます。 - プライマリデータベースが停止している。 - VIPを使用している場合、アドレスはプライマリノードから解放されます。 - スタンバイがプライマリノードを置き換えるように昇格し、VIPを取得します。 - 新しいプライマリノードのアドレスは、メモリに保存されている\ ``primary_conninfo`` の詳細に追加されます。 - このノードに\ ``application.name`` プロパティが設定されている場合、メモリに格納されている\ ``primary_conninfo`` 情報にapplication_nameプロパティが追加されます。 - メモリに保存されたリカバリ設定は、\ ``postgresql.auto.conf`` ファイルに書き込まれます。 ``standby.signal`` ファイルが作成されます。 - 古いプライマリが起動されます。エージェントはスタンバイとしての監視を再開します。 プロモーション中に、プライマリエージェントは仮想IPアドレスを解放します。スイッチオーバーではない場合、\ ``db.data.dir`` プロパティで指定されたディレクトリに\ ``recovery.conf`` ファイルが作成されます。 ``recovery.conf`` ファイルは、ファイルが削除されるまで古いプライマリデータベースが起動しないようにするために使用され、ノードがクラスター内の2番目のプライマリとして起動しないようにします。プロモーションがスイッチオーバーの一部である場合、リカバリ設定は上記のように処理されます。 プライマリエージェントは実行されたままで、ステータスがIdleになります。 スタンバイエージェントは、エージェントがネットワークから分離されていないことを確認する前に、仮想IPアドレスが使用されていないことを確認します。スタンバイエージェントはフェンシングスクリプトを実行し、スタンバイデータベースをプライマリに昇格させます。スタンバイエージェントは、仮想IPアドレスをスタンバイノードに割り当て、プロモーション後スクリプトを実行します該当する場合。 このコマンドは、クラスタープロパティファイルの\ ``auto.failover`` パラメーターで指定された値を無視するようにサービスに指示します。 ノードをプライマリのロールに戻すには、ノードをプロモーションリストの最初に配置します。 ``efm set-priority
`` 次に、手動プロモーションを実行します。 ``efm promote ‑switchover`` efmユーティリティの詳細については、 :ref:`Using the efm utility ` を参照してください。 Failover Managerエージェントの停止 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ エージェントを停止すると、フェールオーバーマネージャーは、クラスターの実行中のすべてのノードのクラスターメンバーリストからノードのアドレスを削除しますが、フェールオーバーマネージャーの許可ノードホストリストからアドレスは削除されません。 RHEL/Rocky Linux/AlmaLinux 8.x以降でFailover Managerエージェントを停止するには、スーパーユーザー権限を引き受けて、コマンドを呼び出します。 ``systemctl stop edb-efm-5.`` ``efm disallow-node`` または\ ``efm reset-members`` コマンド許可ノードホストリストからノードのアドレスを削除を呼び出すまでは、 ``efm allow-node`` コマンドを再度実行せずに、 ``service edb-efm-5. start`` コマンドを使用してエージェントを再起動できます。エージェントをクラスターに追加する予定がない場合は、このエージェントが停止した後に :ref:`efm remote-members ` コマンドを使用することをお勧めします。 :ref:`primary.shutdown.as.failure ` プロパティが\ ``true`` に設定されていない限り、エージェントを停止しても、エージェントに障害が発生したことはクラスターに通知されません。 フェールオーバーマネージャークラスターの停止 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ フェールオーバーマネージャークラスターを停止するには、フェールオーバーマネージャークラスターの任意のノードに接続し、efmまたはOSスーパーユーザーのIDを引き継ぎ、次のコマンドを呼び出します。 ``efm stop-cluster `` このコマンドにより、すべてのFailover Managerエージェントが終了します。フェールオーバーマネージャーエージェントを終了すると、すべてのフェールオーバー機能が完全に無効になります。 .. Note:: `efm stop-cluster` コマンドを呼び出すと、許可されたノードのすべての情報が許可ノードホストリストから失われます。 クラスターからのノードの削除 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``efm disallow-node`` コマンドは、フェールオーバーマネージャー許可ノードホストリストからノードのIPアドレスを削除します。現在実行中のクラスターの一部である既存のノードでefmまたはOSスーパーユーザーのIDを想定しています。次に、ノードのクラスター名とIPアドレスを指定して ``efm disallow-node`` コマンドを呼び出します。 ``efm disallow-node
`` ``efm disallow-node`` コマンドは、実行中のエージェントを停止しません。サービスは、 :ref:`stop the agent <#stop_efm_agent>` までノードで実行され続けます。エージェントまたはクラスターが後で停止された場合、ノードはクラスターに再参加することはできず、フェールオーバー優先リストから削除されます。昇格の対象外となります。 ``efm disallow-node`` コマンドを呼び出した後、 :ref:`efm allow-node ` コマンドを使用してノードをクラスターに再度追加する必要があります。 単一のノードで複数のエージェントを実行する ------------------------------------------ そのフェールオーバーマネージャーノードで複数のプライマリまたはスタンバイエージェントを実行することにより、同じホストにある複数のデータベースクラスターを監視できます。単一のノードで複数の監視エージェントを実行することもできます。別のクラスターのフェールオーバーマネージャーエージェントが相互に干渉しないようにしながら、複数のデータベースクラスターを監視するようにフェールオーバーマネージャーを構成するには 1. 各クラスターのメンバーごとに、クラスター内のノードの一意のプロパティセットとロールを定義するクラスタープロパティファイルを作成します。 2. 各クラスターのメンバーごとに、クラスターのメンバーをリストするクラスターメンバーファイルを作成します。 3. 各クラスターのユニットファイルRHEL/Rocky Linux/AlmaLinux 8.x以降のシステムでをカスタマイズして、クラスタープロパティとクラスターメンバーファイルの名前を指定します。 4. 各クラスターのサービスを開始します。 これらの例では、同じノードで実行されている2つのデータベースクラスターacctgおよびsalesを使用します。 - ``acctg`` のデータは\ ``/opt/pgdata1`` にあります。そのサーバーはポート\ ``5444`` 監視しています。 - ``sales`` のデータは\ ``/opt/pgdata2`` にあります。そのサーバーはポート\ ``5445`` 監視しています。 これらのデータベースクラスターの両方でFailover Managerエージェントを実行するには、 ``efm.properties.in`` テンプレートを使用して2つのプロパティファイルを作成します。各クラスタープロパティファイルには、一意の名前が必要です。この例では、 ``acctg`` および\ ``sales`` データベースクラスターと一致する\ ``acctg.properties`` および\ ``sales.properties`` を作成します。 次のパラメーターは、各クラスタープロパティファイルで一意である必要があります。 ``admin.port`` ``bind.address`` ``db.port`` ``db.data.dir`` ``virtual.ip`` 使用する場合 ``db.service.name`` 使用する場合 各クラスタープロパティファイルで、 ``db.port`` パラメーターは、クラスターごとに一意の値を指定します。 ``db.user`` および\ ``db.database`` パラメーターは、同じ値または一意の値を持つことができます。たとえば、 ``acctg.properties`` ファイルでは次を指定できます。 ``db.user=efm_user`` ``db.password.encrypted=7c801b32a05c0c5cb2ad4ffbda5e8f9a`` ``db.port=5444`` ``db.database=acctg_db`` ``sales.properties`` ファイルでは次を指定できます。 ``db.user=efm_user`` ``db.password.encrypted=e003fea651a8b4a80fb248a22b36f334`` ``db.port=5445`` ``db.database=sales_db`` 一部のパラメーターは、同じノードで複数のフェールオーバーマネージャークラスターエージェントを設定する場合、特別な注意が必要です。複数のエージェントが同じノードにある場合、各ポートは一意である必要があります。任意の2つのポートが機能しますが、互いに近すぎないポートを使用する場合、情報を明確に保つことが簡単です。 クラスターごとにクラスタープロパティファイルを作成するときは、 ``db.data.dir`` パラメーターで、各データベースクラスターごとに一意の値を指定する必要があります。 仮想IPアドレスをノードに割り当てるときに、次のパラメーターを使用します。フェールオーバーマネージャークラスターが仮想IPアドレスを使用しない場合、これらのパラメーターを空白のままにします。 ``virtual.ip`` ``virtual.ip.interface`` ``virtual.ip.prefix`` このパラメーター値は、使用される仮想IPアドレスによって決定され、 ``acctg.properties`` と\ ``sales.properties`` の両方で同じにすることができます。 ``acctg.properties`` および\ ``sales.properties`` ファイルを作成した後、各クラスターのプロパティファイルをポイントするサービススクリプトまたはユニットファイルを作成します。この手順はプラットフォーム固有です。 RHEL/Rocky Linux/AlmaLinux 8.x以降を使用している場合、 :ref:`RHEL/Rocky Linux/AlmaLinux 8.x以降 ` を参照してください。 .. Note:: ユニットファイルを使用している場合は、フェールオーバーマネージャーをアップグレードするときにファイルを手動で更新して、新しいサービス名を反映します。 RHEL/Rocky Linux/AlmaLinux 8.x以降 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ RHEL/Rocky Linux/AlmaLinux 8.x以降を使用している場合、クラスターごとに一意の新しい名前でサービスファイル\ ``/usr/lib/systemd/system/edb-efm-5..service`` ``/etc/systemd/system`` にコピーします。 たとえば、フェールオーバーマネージャー5.2によって管理される\ ``acctg`` および\ ``sales`` という名前の2つのクラスターがある場合、ユニットファイル名は\ ``efm-acctg.service`` および\ ``efm-sales.service`` になります。次を使用して作成できます。 .. code:: shell cp /usr/lib/systemd/system/edb-efm-5.2.service /etc/systemd/system/efm-acctg.service cp /usr/lib/systemd/system/edb-efm-5.2.service /etc/systemd/system/efm-sales.service 次に、 ``systemctl edit`` を使用して、各ユニットファイルの\ ``CLUSTER`` 変数を編集し、指定されたクラスター名を\ ``efm`` から新しいクラスター名に変更します。また、新しいクラスター名と一致するように ``PIDfile`` パラメーターの値を更新します。 この例では、 ``systemctl edit efm-acctg.service`` を実行して\ ``acctg`` クラスターを編集し、次のように書き込みます。 .. code:: ini [Service] Environment=CLUSTER=acctg PIDFile=/run/efm-5.2/acctg.pid ``systemctl edit efm-sales.service`` を実行して\ ``sales`` クラスターを編集し、次のように書き込みます。 .. code:: ini [Service] Environment=CLUSTER=sales PIDFile=/run/efm-5.2/sales.pid !!!注 ``/etc/systemd/system`` のファイルを直接編集することもできますが、 ``systemctl daemon-reload`` を実行する必要があります。 ``systemd edit`` を使用してオーバーライドファイルを変更する場合、この手順は必要ありません。 変更を保存した後、サービスを有効にします。 .. code:: text # systemctl enable efm-acctg.service # systemctl enable efm-sales.service 次に、新しいサービススクリプトを使用してエージェントを起動します。例、\ ``acctg`` エージェントを起動するには .. code:: text # systemctl start efm-acctg ユニットファイルのカスタマイズについては、 `Understanding and administering systemd `_ を参照してください。