Prerequisites

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

Java 1.8（以降）のインストール

Failover Managerを使用する前に、最初にJava（バージョン1.8以降）をインストールする必要があります。 Failover ManagerはOpenJDKでテストされています。そのバージョンのJavaをインストールすることを強くお勧めします。

Installation instructions for Java はプラットフォーム固有です。

SMTPサーバーを提供する

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

  • 電子メール通知を使用している場合、SMTPサーバーはフェールオーバーマネージャーシナリオの各ノードで実行されている必要があります。

  • script.notification プロパティに値を指定する場合、user.email フィールドを空白のままにできます。 SMTPサーバーは必要ありません。

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

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

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

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

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

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 はPostgresバージョンを指定します。

データベースサーバーの自動起動の使用

プライマリノードが再起動すると、フェールオーバーマネージャーは、プライマリノードでデータベースがダウンしていることを検出し、スタンバイノードをプライマリのロールに昇格させる場合があります。これが発生した場合、リブートされたプライマリノードのFailover Managerエージェントはrecovery.conf ファイルを書き込む機会を得られず、 recovery.conf ファイルはデータベースサーバーの起動を妨げます。これが発生した場合、再起動されたプライマリノードは2番目のプライマリノードとしてクラスターに戻ります。

この状態を防ぐには、Failover Managerエージェントがデータベースサーバーの前に自動起動するようにします。エージェントはアイドルモードで起動し、クラスター内に既にプライマリがあるかどうかを確認します。プライマリノードがある場合、エージェントは recovery.conf または standby.signal ファイルが存在することを確認します。どちらのファイルも存在しない場合、エージェントはrecovery.conf ファイルを作成します。

ファイアウォールを介した通信を確保する

フェールオーバーマネージャーノードのホストで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 に設定されている場合：

  • データベースバージョン10以降の場合、 db.userにはpg_read_all_stats 特権とpg_reload_conf() を実行する権限が必要です。

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

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

GRANT pg_read_all_settings TO <user_name>;

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