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

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

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

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

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

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

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

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

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

service efm-3.6 start

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

systemctl start efm-3.6

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

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

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

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

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

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

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

efm allow-nodeコマンドの使用またはフェールオーバーマネージャーサービスの制御の詳細については、「 EFMユーティリティの使用」を参照してください。
フェールオーバーマネージャーエージェントをインストールし、新しいノードでクラスタープロパティファイルを構成します。プロパティファイルの変更の詳細については、クラスタプロパティファイルを参照してください。
新しいノードでクラスターメンバーファイルを構成し、Membership Coordinatorのエントリを追加します。メンバーは、ファイル、クラスタの変更の詳細については、クラスタメンバーファイルを。
新しいノードでスーパーユーザー権限を引き受け、Failover Managerエージェントを起動します。 RHEL 6.xまたはCentOS 6.xでFailover Managerクラスターを起動するには、スーパーユーザー権限を引き受けて、コマンドを呼び出します。
service efm-3.6 start

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

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

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

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

フェールオーバーマネージャークラスターに複数のスタンバイサーバーが含まれる場合、 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つのスタンバイノードに等しく最新のデータが含まれている場合、ユーザーが指定した優先順位の値が高いノードがマスターに昇格します。スタンバイノードの優先度の値を確認するには、次のコマンドを使用します。

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キーワードを含めて、 recovery.confファイルをマスターにコピーするノードを指定します。

スイッチオーバー中の通知を抑制するには、 -quietキーワードを含めます。
-noscriptsキーワードを含めて、フェンシングおよびポストプロモーションスクリプトを呼び出さないようにフェールオーバーマネージャーに指示しないようにします。

スイッチオーバー中：

recovery.confファイルは、既存のスタンバイからマスターノードにコピーされます。
masterデータベースは停止しています。
VIPを使用している場合、アドレスはマスターノードから解放されます。
スタンバイがマスターノードを置き換えるために昇格され、VIPを取得します。
新しいマスターノードのアドレスがrecovery.confファイルに追加されます。
recovery.confファイルにアプリケーション名が含まれ、このノードにapplication.nameプロパティが設定されている場合、アプリケーション名はプロパティ値に置き換えられます。
古いマスターが再起動されます。エージェントはスタンバイとしての監視を再開します。

手動プロモーション中、マスターエージェントは、 db.recovery.conf.dirプロパティで指定されたディレクトリにrecovery.confファイルを作成する前に仮想IPアドレスを解放します。マスターエージェントは実行されたままで、ステータスがIdleます。

スタンバイエージェントは、仮想IPアドレスが使用されていないことを確認してから、既知のアドレスにpingを実行して、エージェントがネットワークから隔離されないようにします。スタンバイエージェントはフェンシングスクリプトを実行し、スタンバイデータベースをマスターに昇格させます。スタンバイエージェントは、仮想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 efm-3.6 stop

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

systemctl stop efm-3.6

efm disallow-nodeコマンド（許可ノードホストリストからノードのノードのアドレスを削除）を呼び出すまでは、 service efm-3.6 startコマンドを使用して、最初にefm allow-node実行せずにノードを再起動できます。再度efm allow-nodeコマンド。

エージェントを停止しても、エージェントに障害が発生したことはクラスターに通知されません。

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

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

efm stop-cluster <cluster_name>

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

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

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

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

efm disallow-node <cluster_name> <ip_address>

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

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

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

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

各クラスターのメンバーごとに、クラスター内のノードの一意のプロパティセットとロールを定義するクラスタープロパティファイルを作成します。
クラスターのメンバーをリストする各クラスターのメンバーごとにクラスターメンバーファイルを作成します。
各クラスターのサービススクリプト（RHELまたはCentOS 6.xシステム）またはユニットファイル（RHELまたはCentOS 7.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.recovery.conf.dir virtualIp （使用する場合） virtualIp.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.recovery.conf.dirパラメーターは、各データベースクラスターに固有の値も指定する必要があります。

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

virtualIp virtualIp.interface virtualIp.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を使用している場合、クラスターごとに一意の名前でefm-3.6サービススクリプトを新しいファイルにコピーする必要があります。例えば：

# cp /etc/init.d/efm-3.6 /etc/init.d/efm-acctg

# cp /etc/init.d/efm-3.6 /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を使用している場合、クラスターごとに一意の名前でefm-3.6ユニットファイルを新しいファイルにコピーする必要があります。たとえば、2つのクラスター（acctgとsalesという名前）がある場合、ユニットファイル名は次のようになります。

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

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

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

Environment=CLUSTER=acctg

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

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

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

# systemctl enable efm-acctg.service

# systemctl enable efm-sales.service