前提条件¶
|variable_prod_name|を設定する前にクラスタでは、以下に説明する前提条件を満たす必要があります。
Java1.8以降をインストールします
|variable_prod_name|を使用する前に、まずJava（バージョン1.8以降）をインストールする必要があります。|variable_prod_name|はOpenJDKでテストされており、そのバージョンのJavaをインストールすることを強くお勧めします。`Javaのインストール手順<https://openjdk.java.net/install/>`__はプラットフォーム固有です。
SMTPサーバーを提供する
|variable_prod_name|から通知を受け取ることができますユーザー定義の通知スクリプト、電子メール、またはその両方で指定されたとおり。
電子メール通知を使用している場合、SMTPサーバーが|variable_prod_name|の各ノードで実行されている必要があります。シナリオ。
script.notificationプロパティに値を指定する場合、user.emailフィールドを空白のままにすることができます。SMTPサーバーは必要ありません。
イベントが発生した場合、|variable_prod_name|スクリプト（提供されている場合）を呼び出し、クラスターのプロパティファイルのuser.emailパラメータで指定されたメールアドレスに通知メールを送信します。SMTPサーバーの使用の詳細については、次のURLにアクセスしてください。
ストリーミングレプリケーションの構成
|variable_prod_name|マスターノードとスタンバイノード間でPostgreSQLストリーミングレプリケーションを構成する必要があります。|variable_prod_name|他のタイプのレプリケーションはサポートしていません。
On database versions 11 (or prior), unless specified with the -sourcenode option, a recovery.conf file is
copied from a random standby node to the stopped master during switchover. You should ensure that the paths within the recovery.conf file on your standby nodes are consistent before performing a switchover. For more information about the -sourcenode option, please see Promoting a Failover Manager Node.
データベースバージョン12では、 primary_conninfo と restore_command のプロパティは、スイッチオーバー中に停止したマスターにコピーされます（ -sourcenode オプションで特に指定されていない限り）。
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ユーザーが接続できるデータベースの名前を指定します。
By default, the pg_hba.conf file resides in the data directory, under
your Postgres installation. After modifying the pg_hba.conf file, you
must reload the configuration file on each node for the changes to take
effect. You can use the following command:
# systemctl reload edb-as-x
x はPostgresのバージョンを指定します。
データベースサーバーの自動起動の使用
If a Master node reboots, |variable_prod_name| may detect the database is down on the Master node and promote a Standby node to the role of Master. If this happens, the |variable_prod_name| agent on the (rebooted) Master node will not get a chance to write the recovery.conf file; the recovery.conf file prevents the database server from starting. If this happens, the rebooted Master node will return to the cluster as a second Master node.
これを防ぐには、|variable_prod_name|を開始しますデータベースサーバーを起動する前のエージェント。エージェントはアイドルモードで起動し、クラスター内に既にマスターがあるかどうかを確認します。マスターノードがある場合、エージェントは recovery.conf または standby.signal ファイルが存在することを確認し、データベースは2番目のマスターとして起動しません。
ファイアウォールを介した通信を保証する
Linuxファイアウォール（iptablesなど）がフェイルオーバーマネージャーノードのホストで有効になっている場合は、ファイアウォール構成にルールを追加して、|variable_prod_name|間のTCP通信を許可する必要がある場合があります。クラスタ内のプロセス。例えば:
# iptables -I INPUT -p tcp --dport 7800:7810 -j ACCEPT
/sbin/service iptables save
上記のコマンドは、狭い範囲のポート（7800から7810）を開きます。|variable_prod_name|クラスタープロパティファイルで指定されたポートに対応するポートを介して接続します。
データベースユーザーに十分な権限があることを確認してください
efm.properties ファイルの db.user プロパティで指定されたデータベースユーザーは、|variable_prod_name|に代わって次の関数を呼び出すための十分な権限を持っている必要があります:
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 の詳細については、`PostgreSQLコアのドキュメントを参照してください<https://www.postgresql.org/docs/12/default-roles.html>`_。