フェイルオーバーマネージャーの使用

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

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

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

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

デフォルトでは、 いくつかのefmコマンド は` 0 ``efm` 0``グループに追加することで、ユーザーがこれらのコマンドを呼び出すことを選択的に許可できます。コマンドは次のとおりです。

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

Failover Managerクラスターのノードは任意の順序で起動できます。

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

service edb-efm-3.9 start

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

systemctl start edb-efm-3.9

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

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

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

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

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

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

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

    efm allow-node <cluster_name ip_address>

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

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

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

  3. 新しいノードでスーパーユーザー権限を想定し、Failover Managerエージェントを起動します。 RHEL 6.xまたはCentOS 6.xでFailover Managerクラスターを起動するには、スーパーユーザー権限を引き受けて、コマンドを呼び出します。

    service edb-efm-3.9 start

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

    systemctl start edb-efm-3.9

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

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

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

Failover Managerクラスターに複数のスタンバイサーバーが含まれる場合、 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でない限り、ユーザー指定の優先度の高いノードがマスターに昇格します。 は` `0``に設定されます。スタンバイノードの優先度の値を確認するには、次のコマンドを使用します。

efm cluster-status <cluster_name>

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

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

フェールオーバーマネージャークラスターの任意のノードで 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 、および promote_trigger_file パラメーターがコピーされ、メモリーに保存されます。

  • masterデータベースは停止しています。

  • VIPを使用している場合、アドレスはマスターノードから解放されます。

  • スタンバイがマスターノードを置き換えるために昇格され、VIPを取得します。

  • 新しいマスターノードのアドレスが recovery.conf ファイルに追加されるか、 primary_conninfo の詳細がメモリーに保存されます。

  • このノードに application.name プロパティが設定されている場合、application_nameプロパティが recovery.conf ファイルに追加されるか、 primary_conninfo 情報がメモリに保存されます。

  • サーバーバージョン12を使用している場合、メモリに保存されているリカバリ設定は postgresql.auto.conf ファイルに書き込まれます。

  • 古いマスターが開始されます。エージェントはスタンバイとしての監視を再開します。

手動プロモーション中、マスターエージェントは仮想IPアドレスを解放してから、 db.data.dir プロパティで指定されたディレクトリに recovery.conf ファイルを作成します。 recovery.conf ファイルはすべてのサーバーバージョンで作成され、ファイルが削除されるまで古いmasterデータベースが起動しないようにし、ノードがクラスター内の2番目のマスターとして起動するのを防ぎます。

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

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

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

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

efm set-priority <cluster_name> <ip_address> <priority>

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

efm promote <cluster_name> ‑switchover

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

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

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

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

service edb-efm-3.9 stop

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

systemctl stop edb-efm-3.9

efm disallow-nodeコマンド（ノードのノードのアドレスを許可ノードホストリストから削除する）を呼び出すまで、 service edb-efm-3.9 start コマンドを使用して、 efm allow-node ``コマンドをもう一度。

master.shutdown.as.failureがなければ、エージェントを停止しても、エージェントが失敗したことをクラスターに通知しないことに注意してください。 プロパティは` `0``に設定されます。

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

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

efm stop-cluster <cluster_name>

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

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

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

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

efm disallow-node <cluster_name> <ip_address>

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

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

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

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

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

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

  3. 各クラスターのサービススクリプト（RHELまたはCentOS 6.xシステム上）またはユニットファイル（RHELまたはCentOS 7.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 （使用する場合）

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 6.xまたはCentOS 6.xを使用している場合は、 RHEL 6.xまたはCentOS 6.xを参照してください。 ; RHEL 7.xまたはCentOS 7.xを使用している場合は、 RHEL 7.xまたはCentOS 7.xを参照してください。 。

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

RHEL 6.xまたはCentOS 6.x

RHEL 6.xまたはCentOS 6.xを使用している場合、 edb-efm-3.9 サービススクリプトを各クラスターに一意の名前で新しいファイルにコピーする必要があります。例:

# cp /etc/init.d/edb-efm-3.9 /etc/init.d/efm-acctg

# cp /etc/init.d/edb-efm-3.9 /etc/init.d/efm-sales

次に、 CLUSTER 変数を編集し、クラスター名を efm から acctg または sales に変更します。

サービススクリプトを作成したら、次を実行します。

# chkconfig efm-acctg on

# chkconfig efm-sales on

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

# service efm-acctg start

RHEL 7.xまたはCentOS 7.x

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

/etc/systemd/system/efm-acctg.service

/etc/systemd/system/efm-sales.service

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

Environment=CLUSTER=acctg

また、 PIDfile パラメーターの値を更新して、新しいクラスター名を指定する必要があります。例:

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

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

# systemctl enable efm-acctg.service

# systemctl enable efm-sales.service

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

# systemctl start efm-acctg

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

http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F