Using Failover Manager

Using Failover Manager#

フェールオーバーマネージャーは、1つ以上のスタンバイサーバーを含むクラスターの監視とフェールオーバーのサポートを提供します。リソースの需要の増加または縮小に応じて、クラスターからノードを追加または削除できます。

プライマリノードが再起動すると、フェールオーバーマネージャーは、プライマリノードでデータベースがダウンしていることを検出し、スタンバイノードをプライマリの役割に昇格させる場合があります。これが発生した場合、リブートされたプライマリノードのFailover Managerエージェントは、recovery.conf ファイルを書き込んで、Postgresがセカンダリプライマリとして起動しないことを確認しようとします。したがって、データベースサーバーを起動する前にFailover Managerエージェントを起動する必要があります。エージェントはアイドルモードで起動し、クラスター内に既にプライマリが存在するかどうかを確認します。プライマリノードがある場合、エージェントはrecovery.conf またはstandby.signal ファイルが存在することを確認するか、必要に応じてrecovery.conf を作成して、データベースがセカンドプライマリとして起動しないようにします。

フェールオーバーマネージャークラスターの管理#

フェールオーバーマネージャークラスターは、一度構成すると、定期的なメンテナンスは必要ありません。ただし、フェールオーバーマネージャークラスターで時折必要になる管理タスクを実行できます。

デフォルトでは、 some of the efm commands はefmまたはOSスーパーユーザーが呼び出す必要があります。管理者は、ユーザーをefmグループに追加することにより、ユーザーがこれらのコマンドを呼び出すことを選択的に許可できます。コマンドは次のとおりです。

フェールオーバーマネージャークラスターの開始#

フェールオーバーマネージャークラスターのノードは、任意の順序で起動できます。

RHEL/Rocky Linux/AlmaLinux 8.x以降でFailover Managerクラスターを起動するには、スーパーユーザー権限を引き受けて、コマンドを呼び出します。

systemctl start edb-efm-5.<x>

注釈

バージョン4.xを使用し、エージェントが起動に失敗した場合、詳細については、起動ログ /var/log/efm-4.<x>/startup-efm.log を参照してください。それ以外の場合は、サービスステータスを参照します。

systemctl status edb-efm-5.<x>

ノードのクラスタープロパティファイルでis.witness がtrue が指定されている場合 、ノードは監視ノードとして起動します。

ノードが専用の監視ノードでない場合、フェールオーバーマネージャーはローカルデータベースに接続し、pg_is_in_recovery() ファンクションを呼び出します。サーバーがfalse に応答した場合、エージェントはノードがプライマリノードであると想定し、必要に応じて仮想IPアドレスをノードに割り当てます。サーバーがtrue に応答した場合、Failover Managerエージェントはノードがスタンバイサーバーであると想定します。サーバーが応答しない場合、エージェントはアイドル状態で起動します。

クラスターに参加した後、Failover Managerエージェントは、指定されたデータベース資格情報を確認して、クラスター内のすべてのデータベースに接続できることを確認します。エージェントが接続できない場合、エージェントはシャットダウンします。

新しいプライマリまたはスタンバイノードがクラスターに参加する場合、既存のすべてのノードも、新しいノードのデータベースに接続できることを確認します。

注釈

tmpfs 一時ファイルシステムで`/var/lock` または`/var/run` を実行している場合、フェールオーバーマネージャーのsystemdサービスファイルが`systemd-tmpfiles-setup.service` に依存していることを確認します。

クラスターへのノードの追加#

ノードはフェールオーバーマネージャークラスターにいつでも追加できます。クラスターにノードを追加するときは、クラスターを変更して新しいノードを許可し、新しいノードにクラスターを見つける方法を指示する必要があります。

  1. auto.allow.hosts がtrue に設定されていない限り、 efm allow-node コマンドを使用して、新しいノードのアドレスをFailover Managerの許可ノードホストリストに追加します。コマンドを呼び出すときに、新しいノードのクラスター名とアドレスを指定します。

efm allow-node <cluster_name> <address>

efm allow-node コマンドの使用またはフェールオーバーマネージャーサービスの制御の詳細については、 efm allow-node を参照してください。

新しいノードにFailover Managerエージェントをインストールし、クラスタープロパティファイルを構成します。プロパティファイルの変更の詳細については、 The cluster properties file を参照してください。

  1. 新しいノードでクラスターメンバーファイルを構成し、メンバーシップコーディネーターのエントリーを追加します。クラスターメンバーファイルの変更の詳細については、 The cluster members file を参照してください。

  2. 新しいノードでスーパーユーザー権限を想定し、Failover Managerエージェントを起動します。 RHEL/Rocky Linux/AlmaLinux 8.x以降でFailover Managerクラスターを起動するには、次のコマンドを呼び出します。

systemctl start edb-efm-5.<x>

新しいノードがクラスターに参加すると、フェールオーバーマネージャーはuser.email プロパティで指定された管理者の電子メールに通知を送信し、指定された通知スクリプトを呼び出します。

注釈

現在のノードの有用なスタンバイになるには、ノードはPostgreSQLストリーミングレプリケーションシナリオでスタンバイである必要があります。

スタンバイの優先度の変更#

フェールオーバーマネージャークラスターに複数のスタンバイサーバーが含まれる場合、 efm set-priority コマンドを使用して、スタンバイノードのプロモーション優先度に影響を与えることができます。フェールオーバーマネージャークラスターの既存のメンバーでコマンドを呼び出し、メンバーのIPアドレスの後に優先度の値を指定します。

たとえば、次のコマンドは、 10.0.1.9 を監視しているacctg クラスターメンバーがプライマリスタンバイ(1) であることをフェールオーバーマネージャーに指示します。

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 コマンドで指定された値は、プロパティファイルの値をオーバーライドします。

efm set-priority acctg 10.0.1.10 1

フェールオーバーが発生すると、フェールオーバーマネージャーは最初にPostgresストリーミングレプリケーションから情報を取得して、どのスタンバイノードに最新のデータがあることを確認し、データ損失の可能性が最も低いノードをプロモートします。 2つのスタンバイノードに同等の最新データが含まれている場合、 use.replay.tiebreaker がtrue に設定されていない限り、ユーザー指定の優先度値が高いノードがプライマリに昇格します。スタンバイノードの優先度値を確認するには、次のコマンドを使用します。

efm cluster-status <cluster_name>

注釈

新しいプライマリが昇格すると、ノードの昇格優先度が変更されます。

efm set-priority コマンドを使用してスタンバイがプロモーション可能かどうかを変更した場合、プロモーションまたはクラスターの分割と再参加を介して、スタンバイのプロパティファイルの値にリセットされる場合があります。エージェントが再起動すると、プロモーション可能ステータスはプロパティファイルの値に戻ります。

フェールオーバーマネージャーノードの昇格#

フェールオーバーマネージャークラスターの任意のノードでefm promote を呼び出して、スタンバイデータベースのプライマリデータベースへの手動プロモーションを開始できます。

データベースクラスターのメンテナンス時間帯にのみ手動プロモーションを実行します。使用可能な最新のスタンバイデータベースがない場合、続行する前にプロンプトが表示されます。手動プロモーションを開始するには、efmまたはOSスーパーユーザーのIDを引き継ぎ、次のコマンドを呼び出します。

efm promote <cluster_name> [-switchover] [-sourcenode <address>] [-quiet] [-noscripts]

そこで

<cluster_name> は、フェールオーバーマネージャークラスターの名前です。

–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 <cluster_name> <address> <priority>

次に、手動プロモーションを実行します。

efm promote <cluster_name> ‑switchover

efmユーティリティの詳細については、 Using the efm utility を参照してください。

Failover Managerエージェントの停止#

エージェントを停止すると、フェールオーバーマネージャーは、クラスターの実行中のすべてのノードのクラスターメンバーリストからノードのアドレスを削除しますが、フェールオーバーマネージャーの許可ノードホストリストからアドレスは削除されません。

RHEL/Rocky Linux/AlmaLinux 8.x以降でFailover Managerエージェントを停止するには、スーパーユーザー権限を引き受けて、コマンドを呼び出します。

systemctl stop edb-efm-5.<x>

efm disallow-node またはefm reset-members コマンド許可ノードホストリストからノードのアドレスを削除を呼び出すまでは、 efm allow-node コマンドを再度実行せずに、 service edb-efm-5.<x> start コマンドを使用してエージェントを再起動できます。エージェントをクラスターに追加する予定がない場合は、このエージェントが停止した後に efm remote-members コマンドを使用することをお勧めします。

primary.shutdown.as.failure プロパティがtrue に設定されていない限り、エージェントを停止しても、エージェントに障害が発生したことはクラスターに通知されません。

フェールオーバーマネージャークラスターの停止#

フェールオーバーマネージャークラスターを停止するには、フェールオーバーマネージャークラスターの任意のノードに接続し、efmまたはOSスーパーユーザーのIDを引き継ぎ、次のコマンドを呼び出します。

efm stop-cluster <cluster_name>

このコマンドにより、すべてのFailover Managerエージェントが終了します。フェールオーバーマネージャーエージェントを終了すると、すべてのフェールオーバー機能が完全に無効になります。

注釈

efm stop-cluster コマンドを呼び出すと、許可されたノードのすべての情報が許可ノードホストリストから失われます。

クラスターからのノードの削除#

efm disallow-node コマンドは、フェールオーバーマネージャー許可ノードホストリストからノードのIPアドレスを削除します。現在実行中のクラスターの一部である既存のノードでefmまたはOSスーパーユーザーのIDを想定しています。次に、ノードのクラスター名とIPアドレスを指定して efm disallow-node コマンドを呼び出します。

efm disallow-node <cluster_name> <address>

efm disallow-node コマンドは、実行中のエージェントを停止しません。サービスは、 stop the agent までノードで実行され続けます。エージェントまたはクラスターが後で停止された場合、ノードはクラスターに再参加することはできず、フェールオーバー優先リストから削除されます。昇格の対象外となります。

efm disallow-node コマンドを呼び出した後、 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以降を使用している場合、 RHEL/Rocky Linux/AlmaLinux 8.x以降 を参照してください。

注釈

ユニットファイルを使用している場合は、フェールオーバーマネージャーをアップグレードするときにファイルを手動で更新して、新しいサービス名を反映します。

RHEL/Rocky Linux/AlmaLinux 8.x以降#

RHEL/Rocky Linux/AlmaLinux 8.x以降を使用している場合、クラスターごとに一意の新しい名前でサービスファイル/usr/lib/systemd/system/edb-efm-5.<x>.service /etc/systemd/system にコピーします。

たとえば、フェールオーバーマネージャー5.2によって管理されるacctg およびsales という名前の2つのクラスターがある場合、ユニットファイル名はefm-acctg.service およびefm-sales.service になります。次を使用して作成できます。

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 クラスターを編集し、次のように書き込みます。

[Service]
Environment=CLUSTER=acctg
PIDFile=/run/efm-5.2/acctg.pid

systemctl edit efm-sales.service を実行してsales クラスターを編集し、次のように書き込みます。

[Service]
Environment=CLUSTER=sales
PIDFile=/run/efm-5.2/sales.pid

!!!注 /etc/systemd/system のファイルを直接編集することもできますが、 systemctl daemon-reload を実行する必要があります。 systemd edit を使用してオーバーライドファイルを変更する場合、この手順は必要ありません。

変更を保存した後、サービスを有効にします。

#  systemctl enable efm-acctg.service

#  systemctl enable efm-sales.service

次に、新しいサービススクリプトを使用してエージェントを起動します。例、acctg エージェントを起動するには

#  systemctl start efm-acctg

ユニットファイルのカスタマイズについては、

Understanding and administering systemd を参照してください。

目次