Using Failover Manager¶

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

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

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

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

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

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

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

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

systemctl start edb-efm-4.<x>

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

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

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

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

注釈

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

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

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

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

efm allow-node <cluster_name> <address>

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

Using the efm utility を参照してください。

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

The cluster properties file を参照してください。

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

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

systemctl start edb-efm-4.<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 キーワードを含めて、フェンシングおよびポストプロモーションスクリプトを呼び出さないようにフェールオーバーマネージャーに指示します。

スイッチオーバー中：

サーバーバージョン11以前の場合、recovery.conf ファイルは既存のスタンバイからプライマリノードにコピーされます。サーバーバージョン12以降では、 primary_conninfo および restore_command パラメーターがコピーされ、メモリに保存されます。

・プライマリデータベースは停止しています。

・ VIPを利用している場合、プライマリノードからアドレスが解放されます。

・プライマリノードに代わってスタンバイが昇格し、VIPを取得します。

新しいプライマリノードのアドレスがrecovery.conf ファイルに追加されるか、 primary_conninfo の詳細がメモリに格納されます。
このノードにapplication.name プロパティが設定されている場合、application_nameプロパティがrecovery.conf ファイルに追加されるか、 primary_conninfo 情報がメモリに格納されます。
サーバーバージョン12以降を使用している場合、メモリに保存されたリカバリ設定はpostgresql.auto.conf ファイルに書き込まれます。 standby.signal ファイルが作成されます。
古いプライマリが起動されます。エージェントはスタンバイとして監視を再開します。

プロモーション中に、プライマリエージェントは仮想IPアドレスを解放します。スイッチオーバーでない場合、 db.data.dir プロパティで指定されたディレクトリにrecovery.conf ファイルが作成されます。 recovery.conf ファイルは、ファイルが削除されるまで古いプライマリデータベースが起動しないようにし、ノードがクラスター内の2番目のプライマリとして起動しないようにするために使用されます。プロモーションがスイッチオーバーの一部である場合、リカバリ設定は上記のように処理されます。

プライマリエージェントは実行されたままで、ステータスがIdleになります。

スタンバイエージェントは、既知のアドレスにpingを実行する前に、仮想IPアドレスが使用されなくなったことを確認して、エージェントがネットワークから分離されていないことを確認します。スタンバイエージェントはフェンシングスクリプトを実行し、スタンバイデータベースをプライマリに昇格させます。スタンバイエージェントは、仮想IPアドレスをスタンバイノードに割り当て、プロモーション後スクリプトを実行します（該当する場合）。

このコマンドは、クラスタープロパティファイルのauto.failover パラメーターで指定された値を無視するようにサービスに指示します。

ノードをプライマリのロールに戻すには、ノードをプロモーションリストの最初に配置します。

efm set-priority <cluster_name> <address> <priority>

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

efm promote <cluster_name> ‑switchover

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

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

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

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

systemctl stop edb-efm-4.<x>

efm disallow-node コマンド（許可ノードホストリストからノードのアドレスを削除）を呼び出すまでは、最初にefm allow-node コマンドを再度実行せずに、 service edb-efm-4.<x> start コマンドを使用してノードを再起動できます。

エージェントを停止しても、 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 コマンドを使用して、ノードをクラスターに再度追加する必要があります。

単一のノードで複数のエージェントを実行する¶

そのFailover Managerノードで複数のプライマリまたはスタンバイエージェントを実行することにより、同じホスト上にある複数のデータベースクラスターを監視できます。単一のノードで複数の監視エージェントを実行することもできます。異なるクラスターのフェールオーバーマネージャーエージェントが互いに干渉しないようにしながら、複数のデータベースクラスターを監視するようにフェールオーバーマネージャーを構成するには:

1.各クラスターのメンバーごとに、クラスター内のノードの一意のプロパティセットとロールを定義するクラスタープロパティファイルを作成します。

各クラスターのメンバーごとに、クラスターのメンバーをリストするクラスターメンバーファイルを作成します。

3.各クラスターのユニットファイル（RHEL/CentOS 7.xまたはRHEL/Rocky Linux/AlmaLinux 8.xシステム上）をカスタマイズして、クラスタープロパティとクラスターメンバーファイルの名前を指定します。

各クラスターのサービスを開始します。

これらの例では、同じノードで実行されている2つのデータベースクラスター（acctgとsales）を使用します。

acctg のデータは/opt/pgdata1 にあります。そのサーバーはポート5444 を監視しています。
sales のデータは/opt/pgdata2 にあります。そのサーバーはポート5445 を監視しています。

これらの両方のデータベースクラスターでFailover Managerエージェントを実行するには、 efm.properties.in テンプレートを使用して2つのプロパティファイルを作成します。各クラスタープロパティファイルには、一意の名前を付ける必要があります。この例では、 acctg.properties およびsales.properties を作成して、 acctg およびsales データベースクラスターに一致します。

次のパラメーターは、各クラスタープロパティファイルで一意である必要があります。

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/CentOS 7.xまたはRHEL/Rocky Linux/AlmaLinux 8.xを使用している場合、

RHEL/CentOS 7.xまたはRHEL/Rocky Linux/AlmaLinux 8.x を参照してください。

注釈

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

RHEL/CentOS 7.xまたはRHEL/Rocky Linux/AlmaLinux 8.x¶

RHEL/CentOS 7.xまたはRHEL/Rocky Linux/AlmaLinux 8.xを使用している場合、edb-efm-4.<x> ユニットファイルを、クラスターごとに一意の名前で新しいファイルにコピーします。たとえば、acctgとsalesという2つのクラスターがある場合、ユニットファイル名は次のようになります。

/usr/lib/systemd/system/efm-acctg.service

/usr/lib/systemd/system/efm-sales.service

次に、各ユニットファイルのCLUSTER 変数を編集し、指定したクラスター名をefm から新しいクラスター名に変更します。たとえば、acctg という名前のクラスターの場合、値は次を指定します。

Environment=CLUSTER=acctg

また、 PIDfile パラメーターの値を更新して、新しいクラスター名を指定します。例：

PIDFile=/var/run/efm-4.7/acctg.pid

サービススクリプトをコピーした後、サービスを有効にします。

#  systemctl enable efm-acctg.service

#  systemctl enable efm-sales.service

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

#  systemctl start efm-acctg`

ユニットファイルのカスタマイズの詳細については、 Understanding and administering systemd を参照してください。