前提条件¶
フェールオーバーマネージャークラスターを構成する前に、以下で説明する前提条件を満たす必要があります。
Java 1.8（以降）をインストールします
Failover Managerを使用する前に、最初にJava（バージョン1.8以降）をインストールする必要があります。 Failover ManagerはOpenJDKでテストされています。そのバージョンのJavaをインストールすることを強くお勧めします。 `Javaのインストール手順<https://openjdk.java.net/install/>`_ はプラットフォーム固有です。
SMTPサーバーを提供する
ユーザー定義の通知スクリプト、電子メール、またはその両方で指定されているように、フェールオーバーマネージャーから通知を受信できます。
電子メール通知を使用している場合、SMTPサーバーがFailover Managerシナリオの各ノードで実行されている必要があります。
script.notificationプロパティに値を指定する場合、user.emailフィールドを空白のままにできます。 SMTPサーバーは必要ありません。
イベントが発生すると、フェールオーバーマネージャーはスクリプト（提供されている場合）を呼び出し、クラスタープロパティファイルのuser.emailパラメーターで指定された任意の電子メールアドレスに通知電子メールを送信します。 SMTPサーバーの使用の詳細については、次を参照してください。
https://access.redhat.com/site/documentation _
ストリーミングレプリケーションの構成
フェールオーバーマネージャーでは、PostgreSQLストリーミングレプリケーションがマスターノードとスタンバイノード間で構成されている必要があります。フェールオーバーマネージャーは、他の種類のレプリケーションをサポートしていません。
データベースバージョン11（またはそれ以前）では、 -sourcenode オプションで指定しない限り、スイッチオーバー中に recovery.conf ファイルがランダムスタンバイノードから停止したマスターにコピーされます。スイッチオーバーを実行する前に、スタンバイノード上の recovery.conf ファイル内のパスが一貫していることを確認する必要があります。 -sourcenode オプションの詳細については、 フェールオーバーマネージャーノードの昇格を参照してください。 。
データベースバージョン12では、スイッチオーバー中に primary_conninfo 、 restore_command 、および promote_trigger_file のプロパティが停止したマスターにコピーされます（ -sourcenode オプションで指定されていない限り）。
レプリケーションスロットを使用してWALセグメントを管理する場合、フェイルオーバーマネージャーは、フェイルオーバー後のスタンバイデータベースの自動再構成をサポートしないことに注意してください。レプリケーションスロットを使用する場合、auto.reconfigureパラメーターをfalseに設定し、フェールオーバーが発生した場合にスタンバイサーバーを手動で再構成する必要があります。
pg_hba.confファイルを変更します
マスターノードとスタンバイノードの pg_hba.conf ファイルを変更し、クラスター内のすべてのノード間の通信を許可するエントリを追加する必要があります。次の例は、マスターノード上のpg_hba.confファイルに作成される可能性のあるエントリを示しています。
# access for itself
host fmdb efm 127.0.0.1/32 md5
# access for standby
host fmdb efm 192.168.27.1/32 md5
# access for witness
host fmdb efm 192.168.27.34/32 md5
どこで:
efmは、有効なデータベースユーザーの名前を指定します。
fmdbは、efmユーザーが接続できるデータベースの名前を指定します。
デフォルトでは、 pg_hba.conf ファイルはPostgresインストールの下の data ディレクトリにあります。 pg_hba.conf ファイルを変更した後、変更を有効にするために各ノードで設定ファイルをリロードする必要があります。次のコマンドを使用できます。
# systemctl reload edb-as-x
ここで、 x はPostgresバージョンを指定します。
データベースサーバーの自動起動の使用
マスターノードが再起動すると、フェールオーバーマネージャーはデータベースがマスターノードでダウンしていることを検出し、スタンバイノードをマスターの役割に昇格させる場合があります。これが発生した場合、（リブートされた）マスターノード上のFailover Managerエージェントは recovery.conf ファイルを書き込む機会を得られません。 recovery.conf ファイルはデータベースサーバーの起動を妨げます。これが発生すると、リブートされたマスターノードは2番目のマスターノードとしてクラスターに戻ります。
これを防ぐには、データベースサーバーを起動する前にFailover Managerエージェントを起動します。エージェントはアイドルモードで起動し、クラスター内に既にマスターが存在するかどうかを確認します。マスターノードがある場合、エージェントは recovery.conf または standby.signal ファイルが存在することを確認し、データベースは2番目のマスターとして起動しません。
ファイアウォールを介した通信を保証
Linuxファイアウォール（iptables）がフェールオーバーマネージャーノードのホストで有効になっている場合、クラスター内のフェールオーバーマネージャープロセス間のtcp通信を許可するルールをファイアウォール構成に追加する必要があります。例:
# iptables -I INPUT -p tcp --dport 7800:7810 -j ACCEPT
/sbin/service iptables save
上記のコマンドは、狭い範囲のポート（7800〜7810）を開きます。フェールオーバーマネージャーは、クラスタープロパティファイルで指定されたポートに対応するポートを介して接続します。
データベースユーザーに十分な権限があることを確認してください
efm.properties ファイルの db.user プロパティで指定されたデータベースユーザーは、フェールオーバーマネージャーに代わって次の機能を呼び出すための十分な権限を持っている必要があります。
pg_current_wal_lsn()
pg_last_wal_replay_lsn()
pg_wal_replay_resume()
pg_reload_conf()
これらの各関数の詳細については、``PostgreSQLコアドキュメント``を参照してください<https://www.postgresql.org/docs/10/static/index.html>`_
ユーザーには、構成変数の値を読み取るためのアクセス許可も必要です。データベースのスーパーユーザーは、PostgreSQLの GRANT コマンドを使用して、必要な権限を提供できます。
GRANT pg_read_all_settings TO user_name;
pg_read_all_settings の詳細については、 pg_read_all_settings を参照してください<https://www.postgresql.org/docs/12/default-roles.html>`_
