前提条件¶
フェールオーバーマネージャークラスターを構成する前に、以下で説明する前提条件を満たす必要があります。
Java 1.8（以降）をインストールします
Failover Managerを使用する前に、最初にJava（バージョン1.8以降）をインストールする必要があります。 Failover ManagerはOpenJDKでテストされています。そのバージョンのJavaをインストールすることを強くお勧めします。 Javaのインストール手順はプラットフォーム固有です。
SMTPサーバーを提供する
ユーザー定義の通知スクリプト、電子メール、またはその両方で指定されたとおりに、フェールオーバーマネージャーから通知を受信できます。
- 電子メール通知を使用している場合、SMTPサーバーがフェールオーバーマネージャーシナリオの各ノードで実行されている必要があります。
- script.notificationプロパティに値を指定する場合、user.emailフィールドを空白のままにできます。 SMTPサーバーは必要ありません。
イベントが発生すると、フェールオーバーマネージャーはスクリプト（提供されている場合）を呼び出し、クラスタープロパティファイルのuser.emailパラメーターで指定された任意の電子メールアドレスに通知電子メールを送信します。 SMTPサーバーの使用の詳細については、次のWebサイトをご覧ください。
https://access.redhat.com/site/documentation
ストリーミングレプリケーションの構成
フェールオーバーマネージャーでは、マスタノードとスタンバイノードの間でPostgreSQLストリーミングレプリケーションを構成する必要があります。フェールオーバーマネージャーは、他の種類のレプリケーションをサポートしません。
-sourcenodeオプションで指定しない限り、recovery.confファイルは、スイッチオーバー中にランダムスタンバイノードから停止したマスターにコピーされます。スイッチオーバーを実行する前に、スタンバイノードのrecovery.confファイル内のパスが一貫していることを確認する必要があります。 -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ファイルを書き込む機会を得られません。再起動されたマスターノードは、2番目のマスターノードとしてクラスターに戻ります。
これを防ぐには、データベースサーバーを起動する前にFailover Managerエージェントを起動します。エージェントはアイドルモードで起動し、クラスター内に既にマスターが存在するかどうかを確認します。マスターノードがある場合、エージェントはrecovery.confファイルが存在することを確認し、データベースは2番目のマスターとして起動しません。
ファイアウォールを介した通信を確保する
Linuxファイアウォール（つまりiptables）がフェールオーバーマネージャーノードのホストで有効になっている場合、クラスター内のフェールオーバーマネージャープロセス間のTCP通信を許可するルールをファイアウォール構成に追加する必要があります。例えば：
# iptables -I INPUT -p tcp --dport 7800:7810 -j ACCEPT
/sbin/service iptables save
上記のコマンドは、狭い範囲のポート（7800〜7810）を開きます。フェールオーバーマネージャーは、クラスタープロパティファイルで指定されたポートに対応するポートを介して接続します。
データベースユーザーに十分な権限があることを確認します
efm.propertiesファイルのdb.userプロパティで指定されたデータベースユーザーには、Failover Managerに代わって次の機能を呼び出すための十分な権限が必要です。
pg_current_wal_lsn()
pg_last_wal_replay_lsn()
pg_wal_replay_pause()
pg_is_wal_replay_paused()
pg_wal_replay_resume()
pg_last_wal_replay_lsn()
これらの各機能の詳細については、 PostgreSQLのコアドキュメントをご覧ください