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は、フェールオーバーイベント中にこのノードを昇格させようとしないことが保証されます。