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

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

If a primary node reboots, Failover Manager may detect the database is down on the Primary node and promote a Standby node to the role of Primary. If this happens, the Failover Manager agent on the (rebooted) Primary node will not get a chance to write the recovery.conf file (for server version 11 or prior) or standby.signal file (for server version 12 or later); the rebooted Primary node will return to the cluster as a second Primary node. To prevent this, start the Failover Manager agent before starting the database server. The agent will start in idle mode, and check to see if there is already a primary in the cluster. If there is a primary node, the agent will verify that a recovery.conf or standby.signal file exists, and the database will not start as a second primary.

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

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

By default, some of the efm commands must be invoked by efm or an OS superuser; an administrator can selectively permit users to invoke these commands by adding the user to the efm group. The commands are:

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

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

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

service edb-efm-4.00 start

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

systemctl start edb-efm-4.00

ノードのクラスタープロパティファイルで 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に追加できますいつでもクラスター。クラスターにノードを追加する場合、クラスターを変更して新しいノードを許可し、クラスターを見つける方法を新しいノードに伝える必要があります。次の手順では、クラスターへのノードの追加について詳しく説明します。

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

efm allow-node <cluster_name ip_address>

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

Failover Managerをインストールしますエージェントを作成し、新しいノードでクラスタープロパティファイルを構成します。プロパティファイルの変更の詳細については、 :doc:`クラスタープロパティファイル<cluster_properties>`を参照してください。
新しいノードでクラスターメンバーファイルを構成し、MembershipCoordinatorのエントリを追加します。クラスターメンバーファイルの変更の詳細については、 :doc:`クラスターメンバーファイル<cluster_members>`を参照してください。
新しいノードでスーパーユーザー権限を想定し、FailoverManagerエージェントを起動します。Failover Managerを開始するにはRHEL6.xまたはCentOS6.x上のクラスター、スーパーユーザー権限を引き受け、コマンドを呼び出します。

service edb-efm-4.00 start

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

systemctl start edb-efm-4.00

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

注意: :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 が上書きされます。

For example, if the properties file on node 10.0.1.10 includes a setting of promotable=false and you use efm set-priority to set the promotion priority of 10.0.1.10 to be the standby used in the event of a failover, the value designated by the efm set-priority command will override the value in the property file:

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>

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

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

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

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

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

どこで:

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

Include the –switchover option to reconfigure the original Primary as a Standby. If you include the –switchover keyword, the cluster must include a primary node and at least one standby, and the nodes must be in sync.

–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 ファイルに書き込まれます。
古いプライマリが開始されます。エージェントはスタンバイとしての監視を再開します。

During a manual promotion, the Primary agent releases the virtual IP address before creating a recovery.conf file in the directory specified by the db.data.dir property. The recovery.conf file is created on all server versions, and is used to prevent the old primary database from starting until the file is removed, preventing the node from starting as a second primary in the cluster.

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

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

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

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

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

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

efm promote <cluster_name> ‑switchover

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

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

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

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

service edb-efm-4.00 stop

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

systemctl stop edb-efm-4.00

Until you invoke the efm disallow-node command (removing the node's address of the node from the Allowed node host list), you can use the service edb-efm-4.0 start command to restart the node at a later date without first running the efm allow-node command again.

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

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

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

efm stop-cluster <cluster_name>

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

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

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

The efm disallow-node command removes the IP address of a node from the Failover Manager Allowed Node host list. Assume the identity of efm or the OS superuser on any existing node (that is currently part of the running cluster), and invoke the efm disallow-node command, specifying the cluster name and the IP address of the node:

efm disallow-node <cluster_name> <ip_address>

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

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

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

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

各クラスターのメンバーごとに、クラスター内のノードの一意のプロパティセットとロールを定義するクラスタープロパティファイルを作成します。
クラスターのメンバーをリストする各クラスターのメンバーごとにクラスターメンバーファイルを作成します。
各クラスターのサービススクリプト（RHELまたはCentOS6.xシステム）またはユニットファイル（RHEL/CentOS7.xまたはRHEL/CentOS8.xシステム）をカスタマイズして、クラスタープロパティの名前とクラスタメンバーファイル。
各クラスターのサービスを開始します。

以下の例では、同じノードで実行されている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 ファイルを作成した後、それぞれのプロパティファイルを指す各クラスターのサービススクリプトまたはユニットファイルを作成します。この手順はプラットフォーム固有です。RHEL6.xまたはCentOS6.xを使用している場合は、 :ref:`RHEL6.xまたはCentOS6.x<rhel_or_centos_6>`を参照してください。RHEL/CentOS7.xまたはRHEL/CentOS8.xを使用している場合は、 :ref:`RHEL/CentOS7.xまたはRHEL/CentOS8.x<rhel_or_centos_7>`を参照してください。

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

RHEL6.xまたはCentOS6.x¶

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

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

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

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

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

# chkconfig efm-acctg on

# chkconfig efm-sales on

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

# service efm-acctg start

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

RHEL/CentOS7.xまたはRHEL/CentOS8.xを使用している場合、 edb-efm-4.0 ユニットファイルを各クラスターに固有の名前で新しいファイルにコピーする必要があります。たとえば、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.00/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