Prerequisites¶

</ div>

フェールオーバーマネージャークラスターを構成する前に、以下で説明する前提条件を満たす必要があります。

Java 1.8（またはそれ以降）をインストールします¶

Failover Managerを使用する前に、最初にJava（バージョン1.8以降）をインストールする必要があります。フェイルオーバーマネージャーはOpenJDKでテストされています。そのバージョンのJavaをインストールすることを強くお勧めします。 Installation instructions for Javaはプラットフォーム固有です。

SMTPサーバーを提供する¶

ユーザー定義の通知スクリプト、メール、またはその両方で指定されたとおりに、フェールオーバーマネージャーから通知を受信できます。

メール通知を使用している場合、フェールオーバーマネージャーシナリオの各ノードでSMTPサーバーが実行されている必要があります。
script.notificationプロパティに値を指定する場合、user.emailフィールドを空白のままにすることができます。 SMTPサーバーは必要ありません。

イベントが発生すると、フェールオーバーマネージャーはスクリプト（提供されている場合）を呼び出し、クラスタープロパティファイルのuser.emailパラメータで指定された任意のメールアドレスに通知メールを送信することもできます。 SMTPサーバーの使用の詳細については、Red Hat deployment guideを参照してください。

ストリーミングレプリケーションを構成する¶

Failover Managerでは、 PostgreSQLストリーミングレプリケーションがプライマリノードとスタンバイノード間で構成されている必要があります。フェールオーバーマネージャーは、他の種類のレプリケーションをサポートしていません。

データベースバージョン11（またはそれ以前）では、-sourcenodeオプションで指定しない限り、スイッチオーバー中にrecovery.confファイルがランダムスタンバイノードから停止したプライマリにコピーされます。スイッチオーバーを実行する前に、スタンバイノードのrecovery.confファイルの経路が一貫していることを確認してください。 -sourcenodeオプションの詳細については、Promoting a Failover Manager nodeを参照してください。

データベースバージョン12以降では、-sourcenodeオプションで特に指定しない限り、スイッチオーバー中にprimary_conninfoおよびrestore_commandプロパティがランダムスタンバイノードから停止したプライマリにコピーされます。

pg_hba.confの変更¶

プライマリノードとスタンバイノードでpg_hba.confを変更し、クラスター内のすべてのノード間の通信を許可するエントリを追加する必要があります。次の例は、プライマリノードのpg_hba.confファイルにmakeエントリを示しています。

#  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 -j ACCEPT
/sbin/service iptables save

このコマンドは、ポート7800を開きます。フェールオーバーマネージャーは、クラスタープロパティファイルで指定されたポートに対応するポート経由で接続します。

データベースユーザに十分な権限があることを確認します¶

efm.propertiesファイルのdb.userプロパティで指定されたデータベースユーザには、フェールオーバーマネージャーに代わって次の機能を呼び出すための十分な権限が必要です。

pg_current_wal_lsn()

pg_last_wal_replay_lsn()

pg_wal_replay_resume()

pg_wal_replay_pause()

reconfigure.num.syncまたはreconfigure.sync.primaryプロパティがtrueに設定されている場合：

データベースバージョン9.6の場合、db。ユーザはスーパーユーザでなければなりません。
バージョン9.6以降のデータベースバージョンの場合、db。ユーザは、pg_reload_conf()を実行するためにpg_read_all_stats権限と許可が必要です。

これらの各関数の詳細については、PostgreSQL core documentationを参照してください。

ユーザには、構成変数の値を読み取るためのアクセス許可も必要です。データベーススーパーユーザは、 PostgreSQL GRANTコマンドを使用して、必要な権限を提供できます。

GRANT pg_read_all_settings TO <user_name>;

pg_read_all_settingsの詳細については、PostgreSQL core documentationを参照してください。