Configuring EFM#
failover_manager がefm
に設定されている場合、TPAはEFMをインストールおよび構成します。
EFMはEDBのパッケージリポジトリを介してのみ利用でき、有効なサブスクリプションが必要であることに注意してください。
EFM構成#
TPAは、適切なインスタンス固有の設定でefm.nodes
およびefm.properties
を生成し、残りの設定はそれぞれのデフォルト値に設定されます。 TPAはまた、
efm.notification.sh
スクリプトも配置します。これは、基本的にデフォルトでは何も含まず、ユーザーが必要に応じて入力するかに任されています。
TPAは、 auto.allow.hosts およびstable.nodes.file
のデフォルト設定をオーバーライドして、クラスターへのエージェントの追加を簡素化します。
EFM documentation を参照してください
EFM構成の詳細については、こちらをご覧ください。
efm_user_password_encryption#
scram-sha-256 またはmd5 のいずれかである必要があります
efm_user_password_encryption を設定して、pg_hba.conf
のefm Postgresユーザーのauth-method のauth-method
と、暗号化されたパスワードを生成するときに使用されるアルゴリズムを制御します。
efm_user_password_encryption: scram-sha-256 # or can be set to `md5`
efm_conf_settings#
efm_conf_settings
を使用して、特定のパラメーターを設定できます。これらは、Ansible辞書のエントリとしてkey: value
フォームで書き込む必要があります
documentation on the `efm.properties file <Configuring EFM>` を参照してください
構成できる設定の詳細については、 を参照してください。
cluster_vars:
efm_conf_settings:
notification.level: WARNING
ping.server.ip: <well known address in network>
efm_conf_settings
の下の値を変更すると、TPAは常にEFMを再起動して変更をアクティブにします。
EFM証人#
TPAは、 role にefm-witness
が含まれるインスタンスに監視としてEFMをインストールおよび構成します。
Repmgr#
EFMはフェールオーバーマネージャーとして機能するため、TPAは引き続きrepmgrをインストールして、postgresバージョン11以下でpostgresqlレプリカをセットアップします。
repmgrd
つまり、この場合、repmgrのデーモンは無効なままで、repmgrの唯一のジョブは、レプリケーションセットアップ機能を提供することです。
postgresバージョン12以降の場合、EFMを使用するクラスターは、pg_basebackup
を使用してスタンバイノードを作成し、どの形式でもrepmgrを使用しません。
ノードのプロモーション#
TPAは、ノードのロールとレプリケーショントポロジに基づいて、フェールオーバー中にノードがEFMによるプロモーションの対象かどうかを判断します。 EFM構成を生成するときに次のルールが適用されます。
Witnessノード
witnessロールはプロモーションできません。``efm-not-promotable`` ロール を持つノードは昇格の資格がありません。これは、DRまたは報告ノードなどの特定のスタンバイがプライマリに昇格しないようにするために使用できます。
カスケードスタンバイ プライマリから直接複製していないノードもプロモーション可能ではありません。
他のすべてのノードは、デフォルトでプロモーション可能であると考えられます。
スタンバイが昇格することを明示的に防ぐには、クラスター構成のノードのroles
リストにefm-not-promotable
を追加します。これにより、EFMは、フェールオーバーイベント中にこのノードを昇格させようとしないことが保証されます。