Prerequisites ============= .. container:: registered_link :name: prerequisites フェールオーバーマネージャークラスターを構成する前に、次の前提条件を満たす必要があります。 Java 11以降のインストール ------------------------- フェールオーバーマネージャーを使用する前に、最初にJavaバージョン11以降をインストールする必要があります。 Failover ManagerはOpenJDKでテストされています。そのバージョンのJavaをインストールすることを強くお勧めします。 `Installation instructions for Java `_ はプラットフォーム固有です。 .. Note:: RHELおよびその派生のOpenJDKバージョン11に一時的な問題があります。フェールオーバーマネージャーを起動すると、次のようなエラーが表示される場合があります。 ``java.lang.Error: java.io.FileNotFoundException: /usr/lib/jvm/java-11-openjdk-11.0.20.0.8-2.el8.x86_64/lib/tzdb.dat (No such file or directory)`` このメッセージが表示された場合、回避策は、 ``sudo dnf install tzdata-java`` コマンドを使用して、不足しているパッケージを手動でインストールすることです。 SMTPサーバーを提供します ------------------------ ユーザー定義の通知スクリプト、電子メール、またはその両方で指定されたとおりに、フェールオーバーマネージャーから通知を受信できます。 - 電子メール通知を使用している場合、フェールオーバーマネージャーシナリオの各ノードでSMTPサーバーが実行されている必要があります。 - ``script.notification`` プロパティに値を指定する場合、\ ``user.email`` フィールドを空白のままにすることができます。 SMTPサーバーは必要ありません。 イベントが発生すると、フェールオーバーマネージャーはスクリプト提供されている場合を呼び出し、クラスタープロパティファイルの\ ``user.email`` パラメーターで指定された任意の電子メールアドレスに通知電子メールを送信することもできます。 SMTPサーバーの使用の詳細については、 `Red Hat deployment guide `_ を参照してください。 ストリーミングレプリケーションの構成 ------------------------------------ フェールオーバーマネージャーでは、プライマリノードとスタンバイノードの間でPostgreSQLストリーミングレプリケーションを構成する必要があります。フェールオーバーマネージャーは、他の種類のレプリケーションをサポートしていません。 ``primary_conninfo`` および\ ``restore_command`` プロパティは、 ``-sourcenode`` オプションで特に指定しない限り、スイッチオーバー中にランダムなスタンバイノードから停止したプライマリにコピーされます。 pg_hba.confを変更します ----------------------- プライマリノードとスタンバイノードで\ ``pg_hba.conf`` を変更し、クラスター内のすべてのノード間の通信を許可するエントリを追加する必要があります。この例は、プライマリノード上の\ ``pg_hba.conf`` ファイルに作成するエントリを示しています。 .. code:: shell # 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`` プロパティで指定されたデータベースユーザーには、Failover Managerに代わって次の機能を呼び出すための十分な権限が必要です。 ``pg_current_wal_lsn()`` ``pg_last_wal_replay_lsn()`` ``pg_wal_replay_resume()`` ``pg_wal_replay_pause()`` ``reconfigure.num.sync`` または\ ``reconfigure.sync.primary`` プロパティが\ ``true`` に設定されている場合、 db.userには\ ``pg_read_all_stats`` 特権と\ ``pg_reload_conf()`` を実行する権限が必要です。 これらの各機能の詳細については、 :ref:`PostgreSQL core documentation ` を参照してください。 ``update.physical.slots.period`` プロパティを使用する場合、 db.userには\ ``REPLICATION`` 特権が必要です。データベーススーパーユーザーは、必要な権限を提供できます。 .. code:: sql ALTER USER REPLICATION; ユーザーは、構成変数の値を読み取る権限も必要です。データベーススーパーユーザーは、 PostgreSQL ``GRANT`` コマンドを使用して、必要な権限を提供できます。 .. code:: sql GRANT pg_read_all_settings TO ; ``pg_read_all_settings`` の詳細については、 `PostgreSQL core documentation `_ を参照してください。