Using Failover Manager

</ div>

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

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

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

構成が完了すると、Failover Managerクラスターは定期的なメンテナンスを必要としません。ただし、Failover Managerクラスターで必要になることがある管理タスクを実行できます。

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

• efm allow-node

• efm disallow-node

• efm promote

• efm resume

• efm set-priority

• efm stop-cluster

• efm upgrade-conf

</ div>

Failover Managerクラスターの起動

Failover Managerクラスターのノードは任意のオーダーでスタートできます。

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

systemctl start edb-efm-4.<x>

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

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

クラスターに参加した後、フェールオーバーマネージャーエージェントは、提供されたデータベース資格情報をチェックして、クラスター内のすべてのデータベースに接続できることを保証します。エージェントが接続できない場合、エージェントはシャットダウンします。

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

</ div>

!!! Note * tmpfs（Temporary File System）でmakeまたは/var/runを実行している場合、Failover Managerのsystemdサービスファイルがsystemd-tmpfiles-setup.serviceに依存していることを確認してください。

クラスターにノードを追加する

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

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

   • efm allow-node <cluster_name> <address>

   • efm allow-nodeコマンドの使用またはFailover Managerサービスの制御の詳細については、Using the efm utilityを参照してください。

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

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

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

• systemctl start edb-efm-4.<x>

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

</ div>

!!! Note * 現在のノードの便利なスタンバイになるには、 PostgreSQL Streaming Replicationシナリオでノードがスタンバイである必要があります。

スタンバイの優先度を変更する

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

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

efm set-priority acctg 10.0.1.9 1

スタンバイをスタンバイ不可にすることができます。スタンバイの優先度を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に設定されていない限り、ユーザー指定の優先順位値が高いノードがorimaryに昇格されます。スタンバイノードの優先度の値を確認するには、次のコマンドを使用します。

efm cluster-status <cluster_name>

</ div>

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

• 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番目のプライマリとして起動しないようにします。プロモーションがスイッチオーバーのパートである場合、リカバリ設定は上記のように処理されます。

プライマリエージェントは実行されたままで、アイドル状態になります。

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

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

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

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

次に、マニュアルプロモーションを実行します。

efm promote <cluster_name> ‑switchover

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

</ div>

Failover Managerエージェントの停止

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

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

systemctl stop edb-efm-4.<x>

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

</ div>エージェントを停止しても、primary.shutdown.as.failureプロパティがtrueに設定されていない限り、エージェントが失敗したことをクラスターにシグナルしません。

Failover Managerクラスターの停止

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

efm stop-cluster <cluster_name>

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

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

クラスターからノードを削除する

efm disallow-nodeコマンドは、ノードのIPアドレスをFailover Managerの許可ノードホストリストから削除します。現在実行中のクラスターのパートである既存のノード上の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コマンドを使用してノードをクラスターに再度追加する必要があります。

</ div>

単一ノードでマルチプルのエージェントを実行する

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

1.各クラスターのメンバごとに、クラスター内のノードの一意のプロパティセットとロールを定義するクラスタープロパティファイルを作成します。クラスターのメンバーをリストする各クラスターのメンバごとにクラスターメンバーファイルを作成します。各クラスターのユニットファイル（RHEL / CentOS 7.xまたはRHEL / CentOS 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.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

同じノードで複数のFailover Managerクラスタエージェントをセットアップする場合、一部のパラメータには特別な注意が必要です。同じノードにマルチプルのエージェントが存在する場合、各ポートは一意である必要があります。任意の2つのポートを使用できますが、互いに近すぎないポートを使用すると、情報を明確に保つことが容易になります。

各クラスターのクラスタープロパティファイルを作成する場合、db.data.dirパラメーターは、各データベースクラスタごとに一意の値も指定する必要があります。

仮想IPアドレスをノードに割り当てるときは、次のパラメーターを使用します。 Failover Managerクラスターが仮想IPアドレスを使用しない場合は、これらのパラメーターを空白のままにします。

virtual.ip

virtual.ip.interface

virtual.ip.prefix

このパラメータ値は、使用されている仮想IPアドレスによって決定され、acctg.propertiesとsales.propertiesの両方で同じになる場合があります。

acctg.propertiesおよびsales.propertiesファイルを作成した後、それぞれのプロパティファイルを指す各クラスターのサービススクリプトまたはユニットファイルを作成します。この手順はプラットフォーム固有です。 RHEL / CentOS 7.xまたはRHEL / CentOS 8.xを使用している場合は、RHEL/CentOS 7.x or RHEL/CentOS 8.xを参照してください。

!!! Note * ユニットファイルを使用している場合、Failover Managerのアップグレード時に新しいサービス名前を反映するようにファイルを手動で更新します。

RHEL / CentOS 7.xまたはRHEL / CentOS 8.x

RHEL / CentOS 7.xまたはRHEL / CentOS 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.4/acctg.pid

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

#  systemctl enable efm-acctg.service

#  systemctl enable efm-sales.service

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

#  systemctl start efm-acctg`

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