Using Failover Manager

|Failover Manager1つ以上のスタンバイサーバーを使用したクラスターの監視とフェールオーバーのサポートを提供します。リソースの需要が増加または減少するにつれて、クラスターにノードを追加または削除できます。

プライマリノードが再起動する場合、|Failover Managerデータベースがプライマリノードでダウンしていることを検出し、スタンバイノードをプライマリの役割に昇格させる場合があります。この場合、|Failover Manager（リブートされた）プライマリノード上のエージェントは、 recovery.conf ファイルを書き込む機会を得られません。再起動されたプライマリノードは、2番目のプライマリノードとしてクラスタに戻ります。これを防ぐには、|Failover Managerを開始しますデータベースサーバーを起動する前のエージェント。エージェントはアイドルモードで起動し、クラスターに既にプライマリがあるかどうかを確認します。プライマリノードがある場合、エージェントは recovery.conf または standby.signal ファイルが存在することを確認し、データベースは2番目のプライマリとして起動しません。

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

構成すると、|Failover Managerクラスターは定期的なメンテナンスを必要としません。以下のセクションでは、フェールオーバーマネージャークラスターで必要になることがある管理タスクの実行に関する情報を提供します。

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

フェールオーバーマネージャークラスターの起動

|Failover Managerのノードを開始できます任意の順序でクラスター化します。

|Failover Managerを開始するにはRHEL/CentOS7.xまたはRHEL/CentOS8.x上のクラスター、スーパーユーザー権限を引き受け、コマンドを呼び出します。

systemctl start edb-efm-4.1

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

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

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

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

注釈

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

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

ノードをFailover Managerに追加できますいつでもクラスター。クラスターにノードを追加する場合、クラスターを変更して新しいノードを許可し、クラスターを見つける方法を新しいノードに伝える必要があります。次の手順では、クラスターへのノードの追加について詳しく説明します。

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

    efm allow-node <cluster_name> <address>

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

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

  2. 新しいノードでクラスターメンバーファイルを構成し、MembershipCoordinatorのエントリを追加します。クラスターメンバーファイルの変更の詳細については、 クラスターメンバーファイル を参照してください。

  3. 新しいノードでスーパーユーザー権限を想定し、FailoverManagerエージェントを起動します。|Failover Managerを開始するにはRHEL/CentOS7.xまたはRHEL/CentOS8.x上のクラスターで、次のコマンドを呼び出します。

    systemctl start edb-efm-4.1

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

Please note: :現在のノードの便利なスタンバイになるには、PostgreSQLストリーミングレプリケーションシナリオでノードがスタンバイでなければなりません。

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

あなたのFailover Managerクラスターに複数のスタンバイサーバーが含まれる場合、 efm set-priority コマンドを使用してスタンバイノードのプロモーション優先度に影響を与えることができます。|Failover Managerの既存のメンバーでコマンドを呼び出しますクラスター、およびメンバーのIPアドレスの後に優先順位値を指定します。

たとえば、次のコマンドはFailover Managerを指示します 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

フェイルオーバーの場合、|Failover Manager最初にPostgresストリーミングレプリケーションから情報を取得して、どのスタンバイノードに最新のデータがあるかを確認し、データ損失の可能性が最も低いノードを昇格させます。2つのスタンバイノードに等しく最新のデータが含まれている場合、 use.replay.tiebreaker<use.replay.tiebreaker>`が ``false` スタンバイノードの優先度の値を確認するには、次のコマンドを使用します。

efm cluster-status <cluster_name>

Please note: :ノードがクラスターから分離され、後でクラスターに再び参加すると、プロモーションの優先順位が変更される場合があります。

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

|Failover Managerの任意のノードで efm promote を呼び出すことができますスタンバイデータベースのプライマリデータベースへの手動昇格を開始するクラスター。

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

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

場所:

<cluster_name> はFailover Managerクラスターの名前です。

–switchover オプションを含めて、元のプライマリをスタンバイとして再構成します。 –switchover キーワードを含める場合、クラスターにはプライマリノードと少なくとも1つのスタンバイが含まれている必要があり、ノードは同期している必要があります。

–sourcenode キーワードを含めて、リカバリ設定がプライマリにコピーされるノードを指定します。

スイッチオーバー中の通知を抑制するには、 -quiet キーワードを含めます。

指示を防ぐために -noscripts キーワードを含めますFailover Managerフェンシングおよびポストプロモーションスクリプトを呼び出さないようにします。

切り替え中:

  • サーバーバージョン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アドレスを解放します。スイッチオーバーではない場合、recovery.confファイルがdb.data.dirプロパティで指定されたディレクトリに作成されます。recovery.confファイルは、ファイルが削除されるまで古いプライマリデータベースが起動しないようにするために使用され、ノードがクラスタ内の2番目のプライマリとして起動するのを防ぎます。昇格がスイッチオーバーの一部である場合、回復設定は上記のように処理されます。

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

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

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

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

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

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

efm promote <cluster_name> ‑switchover

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

フェールオーバーマネージャーエージェントの停止

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

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

systemctl stop edb-efm-4.1

「許可ノードホストリストからノードのノードのアドレスを削除する」 efm disallow-node コマンドを呼び出すまで、 efm allow-node コマンドを再度実行することなく、 service edb-efm-4.1 start コマンドを使用して後日ノードを再起動できます。

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

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

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

efm stop-cluster <cluster_name>

このコマンドは*all* |Failover Managerを引き起こします終了するエージェント。|Failover Managerの終了エージェントは、すべてのフェイルオーバー機能を完全に無効にします。

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

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

efm disallow-node コマンドは、ノードのIPアドレスをFailover Managerから削除します許可ノードホストリスト。既存のノード（現在実行中のクラスターの一部）の efm またはOSスーパーユーザーのIDを想定し、 efm disallow-node コマンドを呼び出して、クラスター名とノードのIPアドレスを指定します。

efm disallow-node <cluster_name> <address>

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

efm disallow-node コマンドを呼び出した後、 efmallow-node コマンドを使用して、ノードをクラスターに再度追加する必要があります。

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

|Failover Managerで複数のプライマリエージェントまたはスタンバイエージェントを実行することにより、同じホストにある複数のデータベースクラスターを監視できます。ノード。単一のノードで複数のウィットネスエージェントを実行することもできます。|Failover Managerを構成するにはFailover Managerを確保しながら、複数のデータベースクラスターを監視する異なるクラスターのエージェントは互いに干渉しないため、以下を行う必要があります。

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

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

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

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

以下の例では、同じノードで実行されている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 （使用する場合）

virtual.ip.interface （使用する場合）

各クラスタープロパティファイル内で、 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/CentOS7.xまたはRHEL/CentOS8.xを使用している場合は、 RHEL/CentOS7.xまたはRHEL/CentOS8.x を参照してください。

Please note: :ユニットファイルを使用している場合、|Failover Managerをアップグレードするときに、新しいサービス名を反映するようにファイルを手動で更新する必要があります。

RHEL/CentOS7.xまたはRHEL/CentOS8.x

RHEL/CentOS7.xまたはRHEL/CentOS8.xを使用している場合は、 edb-efm-4.1 ユニットファイルを、クラスターごとに一意の名前を持つ新しいファイルにコピーする必要があります。たとえば、2つのクラスター（acctgとsalesという名前）がある場合、ユニットファイル名は次のようになります。

/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.1/acctg.pid

サービススクリプトをコピーした後、次のコマンドを使用してサービスを有効にします。

# systemctl enable efm-acctg.service

# systemctl enable efm-sales.service

次に、新しいサービススクリプトを使用してエージェントを起動します。たとえば、次のコマンドで acctg エージェントを起動できます。

# systemctl start efm-acctg

ユニットファイルのカスタマイズについては、次をご覧ください。

https://docs.fedoraproject.org/en-US/quick-docs/understanding-and-administering-systemd/index.html