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

|variable_prod_name|は、1つ以上のスタンバイサーバーを持つクラスターの監視とフェールオーバーをサポートします。リソースの需要が増加または縮小するときに、クラスターからノードを追加または削除できます。

If a Master node reboots, |variable_prod_name| may detect the database is down on the Master node and promote a Standby node to the role of Master. If this happens, the |variable_prod_name| agent on the (rebooted) Master 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 Master node will return to the cluster as a second Master node. To prevent this, start the |variable_prod_name| agent before starting the database server. The agent will start in idle mode, and check to see if there is already a master in the cluster. If there is a master node, the agent will verify that a recovery.conf or standby.signal file exists, and the database will not start as a second master.

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

設定したら、|variable_prod_name|クラスタは定期的なメンテナンスを必要としません。次のセクションでは、フェールオーバーマネージャークラスターで必要になる場合がある管理タスクの実行について説明します。

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:

FailoverManagerクラスターの起動

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

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

service edb-efm-|variable_prod_version| start

|variable_prod_name|を開始するにはRHEL/CentOS7.xまたはRHEL/CentOS8.xでクラスターを作成し、スーパーユーザー特権を引き受けて、次のコマンドを呼び出します。

systemctl start edb-efm-|variable_prod_version|

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

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

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

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

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

|variable_prod_name|にノードを追加できますいつでもクラスター。クラスタにノードを追加するときは、新しいノードを許可するようにクラスタを変更してから、新しいノードにクラスタの検索方法を伝える必要があります。次の手順では、クラスターへのノードの追加について詳しく説明します。

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

    efm allow-node <cluster_name ip_address>

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

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

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

  3. 新しいノードでスーパーユーザー権限を引き受け、フェイルオーバーマネージャーエージェントを起動します。|variable_prod_name|を開始するにはRHEL6.xまたはCentOS6.xでクラスター化し、スーパーユーザー権限を引き受け、次のコマンドを呼び出します。

service edb-efm-|variable_prod_version| start

|variable_prod_name|を開始するにはRHEL/CentOS7.xまたはRHEL/CentOS8.xでクラスターを作成し、スーパーユーザー特権を引き受けて、次のコマンドを呼び出します。

systemctl start edb-efm-|variable_prod_version|

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

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

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

|variable_prod_name|クラスターに複数のスタンバイサーバーが含まれている場合、 efm set-priority コマンドを使用して、スタンバイノードの昇格の優先度に影響を与えることができます。|variable_prod_name|の既存のメンバーでコマンドを呼び出すクラスタ、およびメンバーのIPアドレスの後に優先度の値を指定します。

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

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

efm cluster-status <cluster_name>

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

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

|variable_prod_name|の任意のノードで efm promote を呼び出すことができますクラスタを使用して、スタンバイデータベースからマスターデータベースへの手動昇格を開始します。

手動昇格は、データベースクラスターのメンテナンス期間中にのみ実行する必要があります。最新のスタンバイデータベースがない場合は、続行する前にプロンプトが表示されます。手動昇格を開始するには、efmまたはOSスーパーユーザーのIDを想定して、次のコマンドを呼び出します。

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

どこ:

<cluster_name> は|variable_prod_name|の名前です集まる。

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

リカバリ設定のマスターからのコピー元のノードを指定するには、 –sourcenode キーワードを含めます。

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

Include the -noscripts keyword to prevent instruct |variable_prod_name| to not invoke fencing and post-promotion scripts.

スイッチオーバー中:

  • サーバーバージョン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 Master 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 master database from starting until the file is removed, preventing the node from starting as a second master in the cluster.

マスターエージェントは実行中のままで、ステータスは Idle になります。

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

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

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

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

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

efm promote <cluster_name> ‑switchover

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

FailoverManagerエージェントの停止

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

|variable_prod_name|を停止するにはRHEL6.xまたはCentOS6.xのエージェントで、スーパーユーザー権限を引き受け、次のコマンドを実行します。

service edb-efm-|variable_prod_version| stop

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

systemctl stop edb-efm-|variable_prod_version|

efmdisallow-nodeコマンドを呼び出す（許可されたノードのホストリストからノードのノードのアドレスを削除する）まで、 service edb-efm-3.10 start コマンドを使用して、最初に efm allow-node を実行せずに後でノードを再起動できます``コマンドをもう一度。

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

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

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

efm stop-cluster <cluster_name>

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

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

クラスターからのノードの削除

The efm disallow-node command removes the IP address of a node from the |variable_prod_name| 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 コマンドは実行中のエージェントを停止しません。 エージェントを停止するまで、サービスはノードで実行され続けます。その後エージェントまたはクラスターが停止した場合、ノードはクラスターに再参加することができず、フェイルオーバー優先順位リストから削除されます（昇格の対象外になります）。

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

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

|variable_prod_name|で複数のマスターまたはスタンバイエージェントを実行することにより、同じホスト上にある複数のデータベースクラスターを監視できます。ノード。単一のノードで複数の監視エージェントを実行することもできます。|variable_prod_name|を設定するには|variable_prod_name|を確認しながら、複数のデータベースクラスターを監視する異なるクラスターのエージェントは相互に干渉しません。

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

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

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

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

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

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

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

|variable_prod_name|を実行するにはこれらの両方のデータベースクラスタのエージェントでは、 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

|variable_prod_name|を複数設定する場合、一部のパラメーターには特別な注意が必要です。同じノード上のクラスタエージェント。複数のエージェントが同じノードに存在する場合、各ポートは一意である必要があります。どの2つのポートでも機能しますが、相互に近すぎないポートを使用する場合は、情報を明確にしておく方が簡単な場合があります。

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

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

virtual.ip

virtual.ip.interface

virtual.ip.prefix

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

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

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

RHEL6.xまたはCentOS6.x

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

# cp /etc/init.d/edb-efm-|variable_prod_version| /etc/init.d/efm-acctg

# cp /etc/init.d/edb-efm-|variable_prod_version| /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-3.10 ユニットファイルを、クラスターごとに一意の名前で新しいファイルにコピーする必要があります。たとえば、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-|variable_prod_version|/acctg.pid

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

# systemctl enable efm-acctg.service

# systemctl enable efm-sales.service

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

# systemctl start efm-acctg

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

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