Configuring EFM

Configuring EFM#

failover_manager がefm に設定されている場合、TPAはEFMをインストールおよび構成します。

efm_version を変更することにより、使用するEFMのバージョンを構成できます。

cluster_vars:
  …
  failover_manager: efm
  efm_version: 5.2
  …

tpaexec configure の実行時に定義することもできます。

tpaexec configure my-cluster-dir -a M1 --failover_manager efm --efm-version 5.2

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` です。

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 <https://www.enterprisedb.com/docs/efm/latest/04_configuring_efm/01_cluster_properties/>`_ を参照してください

構成できる設定の詳細については、 を参照してください。

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をインストールおよび構成します。EFMを使用する場合、暗黙的にefm-witness に変換されるため、ロールwitness を使用することもできます。 このようなインスタンスの場合、 upstream プロパティを指定して、指定されたプライマリデータベースインスタンスをポイントする必要があります。

Repmgr#

EFMはフェールオーバーマネージャーとして機能するため、TPAは引き続きrepmgrをインストールして、postgresバージョン11以下でpostgresqlレプリカをセットアップします。 repmgrd つまり、この場合、repmgrのデーモンは無効なままで、repmgrの唯一のジョブは、レプリケーションセットアップ機能を提供することです。

postgresバージョン12以降の場合、EFMを使用するクラスターは、pg_basebackup を使用してスタンバイノードを作成し、どの形式でもrepmgrを使用しません。

ノードのプロモーション#

TPAは、ノードのロールとレプリケーショントポロジに基づいて、フェールオーバー中にノードがEFMによるプロモーションの対象かどうかを判断します。 EFM構成を生成するときに次のルールが適用されます。

  • Witnessノード efm-witness ロールはプロモーションできません。

  • ``efm-not-promotable`` ロール を持つノードは昇格の資格がありません。これは、DRまたは報告ノードなどの特定のスタンバイがプライマリに昇格しないようにするために使用できます。

  • カスケードスタンバイ プライマリから直接複製していないノードもプロモーション可能ではありません。

  • 他のすべてのノードは、デフォルトでプロモーション可能であると考えられます。

スタンバイが昇格することを明示的に防ぐには、クラスター構成のノードのroles リストにefm-not-promotable を追加します。これにより、EFMは、フェールオーバーイベント中にこのノードを昇格させようとしないことが保証されます。

tpaexec upgrade を使用したEFMのマイナー更新#

TPAは、新しいバージョンのパッケージをインストールし、構成ファイルを既存のEFMバージョンの構成ディレクトリから新しいEFMバージョンの構成ディレクトリにコピーし、クリーンアップのために既存のEFMバージョンのパッケージ、サービスファイル、およびバイナリディレクトリを削除します。

EFMアップグレードは、インストールおよび構成されている以前のバージョンソースに依存しているため、TPAは最初にこれがtrueを確認します。ソースEFMバージョンがインストールされていない場合、バイナリディレクトリが存在しない、または構成されていないイベント、構成ディレクトリが存在しない場合、アップグレードはエラーで終了します。アップグレードを実行するときに、ターゲットEFMバージョン config.yml のefm_version で指定に既にバイナリディレクトリと構成ディレクトリがある場合、EFMは既にインストールされ、目的のバージョンに構成されているため、アップグレードはEFMをスキップします。

注釈

EFMアップグレードは、つまりマイナーアップグレードでなくても、EFM 4.9から5.0からサポートされています。このアップグレードを発生させるために追加の手順は必要ありません。

component selection for upgrade のセクションを参照してください

詳細については、

注釈

EFMは、混合バージョン環境では動作できません。この制限のため、EFMコンポーネントの部分的なアップグレードをサポートする十分な理由はありません。 efm がアップグレードするコンポーネントのリストの一部である場合、TPAは**常に**、EFMノードの完全なセットでEFMソフトウェアをアップグレードします。 TPAは、どのノードをEFMをアップグレードする必要があるかを決定するときに`update_hosts` を無視します。 !!!

目次