Configuring EFM =============== ``failover_manager`` が\ ``efm`` に設定されている場合、TPAはEFMをインストールおよび構成します。 ``efm_version`` を変更することにより、使用するEFMのバージョンを構成できます。 .. code:: yaml cluster_vars: … failover_manager: efm efm_version: 5.2 … ``tpaexec configure`` の実行時に定義することもできます。 .. code:: shell 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`` と、暗号化されたパスワードを生成するときに使用されるアルゴリズムを制御します。 .. Note:: 新しいクラスターの`efm_user_password_encryption` のデフォルト値は`scram-sha-256` です。 .. code:: yaml 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 `_ を参照してください 構成できる設定の詳細については、 を参照してください。 .. code:: yaml cluster_vars: efm_conf_settings: notification.level: WARNING ping.server.ip: ``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のマイナー更新 ----------------------------------------------- .. Note EFM is *not* a package update:: EFMバージョンのリリース方法により、各EFMマイナーバージョンには、独自のバイナリと構成ディレクトリをインストールする独自のパッケージv4.9の`edb-efm49` 、v5.0の`edb-efm50` などがあります。 .. :: EFMをアップグレードするときは、 `config.yml` の`efm_version` を設定して、目的のバージョンを反映します。 TPAは、新しいバージョンのパッケージをインストールし、構成ファイルを既存のEFMバージョンの構成ディレクトリから新しいEFMバージョンの構成ディレクトリにコピーし、クリーンアップのために既存のEFMバージョンのパッケージ、サービスファイル、およびバイナリディレクトリを削除します。 EFMアップグレードは、インストールおよび構成されている以前のバージョンソースに依存しているため、TPAは最初にこれがtrueを確認します。ソースEFMバージョンがインストールされていない場合、バイナリディレクトリが存在しない、または構成されていないイベント、構成ディレクトリが存在しない場合、アップグレードはエラーで終了します。アップグレードを実行するときに、ターゲットEFMバージョン ``config.yml`` の\ ``efm_version`` で指定に既にバイナリディレクトリと構成ディレクトリがある場合、EFMは既にインストールされ、目的のバージョンに構成されているため、アップグレードはEFMをスキップします。 .. Note:: EFMアップグレードは、つまりマイナーアップグレードでなくても、EFM 4.9から5.0からサポートされています。このアップグレードを発生させるために追加の手順は必要ありません。 .. :: アップグレードのためにEFMを選択するには、 `tpaexec upgrade` コマンドに渡される`--components` フラグに `efm` または`all` が含まれていることを確認します :ref:`component selection for upgrade ` のセクションを参照してください 詳細については、 .. Note:: EFMは、混合バージョン環境では動作できません。この制限のため、EFMコンポーネントの部分的なアップグレードをサポートする十分な理由はありません。 `efm` がアップグレードするコンポーネントのリストの一部である場合、TPAは**常に**、EFMノードの完全なセットでEFMソフトウェアをアップグレードします。 TPAは、どのノードをEFMをアップグレードする必要があるかを決定するときに`update_hosts` を無視します。 !!!