Prerequisites

Prerequisites#

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

Java 11以降のインストール#

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

フェールオーバーマネージャーエージェントが使用しているJavaのバージョンを更新または変更する前に、エージェントを停止し、更新後に再度起動する必要があります。これはOSのアップグレードにも適用され、エージェントが使用しているJavaインストールが変更される可能性があります。 Configuring for Eager Failover を使用しない限り、エージェントを停止しても実行中のデータベースサーバーに影響はありません。

注釈

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 ファイルに作成するエントリを示しています。

#  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を開きます。フェールオーバーマネージャーは、クラスタープロパティファイルのbind.address で指定されたポートに対応するポートを介して接続します。 admin.port で指定されたポートを開く必要はありません。 efmユーティリティが実行されるときに、ローカル通信にのみ使用されます。

データベースユーザーが十分な権限を持っていることを確認します#

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() を実行する権限が必要です。

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

update.physical.slots.period プロパティを使用する場合、 db.userにはREPLICATION 特権が必要です。データベーススーパーユーザーは、必要な権限を提供できます。

ALTER USER <user_name> REPLICATION;

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

GRANT pg_read_all_settings TO <user_name>;

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

目次