Trusted Postgres Architect 23.44.0 release notes

Trusted Postgres Architect 23.44.0 release notes#

リリース日2026年6月10日

Trusted Postgres Architect 23.44.0の新機能、機能強化、バグ修正、およびその他の変更には次のものが含まれます。

ハイライト#

  • PGD-Xクラスター内のコンポーネントのアップグレードのサポート

  • PGDアップグレードの堅牢性の向上

  • EFMユーザーはデフォルトでスーパーユーザーでなくなりました

機能強化#

Description

Addresses

TPAは、 PGD-Xアーキテクチャのコンポーネントのアップグレードをサポートするようになりました。 PGD-Xのアップグレードプレイブックには、tpaexec `tpaexec upgrade (...) --components=<component>`を介して選択したコンポーネントPgBouncer、pg-backup-api、 Barman、PEMサーバーを確実にアップグレードする追加手順が含まれているため、個々のコンポーネントは必要なくアップグレードできます。クラスター全体をアップグレードします。このアップグレードプロセスは、コンポーネントのアップグレード、マイナーPGD-Xアップグレード、およびPGD-Xアーキテクチャへのメジャーアップグレードのスタンドアロン機能として含まれています。

TPAは、必要な最小限の権限のみでEFMデータベースユーザーを展開できるようになりました。通常のEFM展開では、TPAはEFMユーザーにSUPERUSER特権を付与しました。 `efm_user_is_superuser`と呼ばれる新しい変数が導入され、TPAはPostgres SUPERUSERとして、または特定のカタログ機能と事前定義されたロールpg_monitor、 EFMが必要とするpg_read_all_settings、pg_read_all_stats変数はスイッチとして機能し、通常の展開で切り替えることができ、既に展開されたクラスターで使用してEFMユーザーの特権を切り替えることができます。

TPAがAnsible Automation Platform 2.6をサポートするようになりました。 TPAはAAP 2.6でテストされています。既存の実行環境は、AAP 2.4およびAAP 2.6の両方と互換性があります。

PGD 5からPGD 6へのアップグレード中にプロキシモニタリングのサポートを追加しました。 `tpaexec upgrade`への`enable_proxy_monitoring=yes`オプションは、 PGD-Always-ON PGD 5からPGD-X PGD 6へのアップグレード中に使用できるようになりました。以前は、モニタが接続マネージャーを実行しない監視ノードの接続マネージャーポートに接続しようとしたため、アップグレードがすぐに失敗していました。 Witnessノードが、監視のターゲットであるエンドポイントのリストから除外されます。

TPAはデフォルト以外の巨大ページサイズをサポートするようになりました。 TPAのhugepages設定は、以前にアーキテクチャのデフォルトのページサイズx86_64で2MBを想定していたため、Postgresで1GB huge pageを使用する構成では、ユーザーがカーネルコマンドライン、vm.nr_hugepages sysctl、および`huge_page_size` GUC、および値を設定する必要がありました生成されたTPAはそれらに対して作用しました。 TPAは、 huge_page_size`変数 `1GB`などのPostgresスタイルのメモリ文字列をサポートするようになりました。設定されると、TPAは`hugepagesz=`を使用してカーネルコマンドラインでそのサイズのページを予約し、/etc/sysctl.conf`から`vm.nr_hugepages`を省略し、アーキテクチャのデフォルトサイズのプールにのみ適用され、Postgresが選択されたプールから描画するように`huge_page_size`を`postgresql.conf`に設定します。ページ数は、新しい`nr_hugepages`変数でオーバーライドできます。下位互換性のため、 `nr_hugepages`が明示的に設定されていない場合でも、既存の`sysctl_values['vm.nr_hugepages']`が優先されます。すべての予約はブート時に通常のメモリから取得されるため、 `huge_page_size`は、通常、クラスター全体ではなく個々のPostgresインスタンスで設定するのが最適です。

repmgrサービスユニットファイルに環境変数オプションを追加しました。 `repmgr_service_environment`と呼ばれる新しい変数がrepmgrのrepmgrサービスユニットテンプレートファイルに追加されました。この変数を使用すると、ユーザーはrepmgrサービスに設定されるカスタム環境変数を指定できます。 `repmgr_service_environment`変数は、クラスター構成ファイルに、キーが環境変数の名前であり、値がこれらの変数に対応する値である辞書として定義できます。これは、repmgrプロセスがカスタムライブラリパスや認証資格情報など、特定のランタイム値へのアクセスが必要な環境に役立ちます。

56200

TPAの選択したPythonインタープリターとパッケージに対して、サポートされているcluster_varsオーバーライドを追加しました。 2つの新しいまたは新しく有効なcluster_varsが、TPAがクラスターノードでPythonを使用する方法を制御するようになりました。詳細については、 `docs/src/python.md`を参照してください。複数のPythonインタープリターがインストールされているホストで2つの変数をカップリングすることの推奨を含みます。

TPAは、PGD 6マイナーアップグレード中にenable_proxy_monitoringをサポートするようになりました。 `tpaexec upgrade`への`enable_proxy_monitoring=yes`オプションは、既にサポートされていたメジャーアップグレードパスに加えて、PGD 6からPGD 6のマイナーアップグレードでも機能するようになりました。 TPAは有効にすると、ローリングフェンス/再起動サイクル中に各データノードで接続マネージャーのダウンタイムを記録します。

再起動とサービスの除外タスクのカバレッジが向上しました。 TPAは、 Barman、beacon-agent、EFM、etcd、harp、Patroni、PEMエージェントとサーバー、pgbackupapi、PgBouncer、PGDプロキシを含むサービスの再起動またはsystemdサービス管理を実行するすべてのロールにわたって`excluded_tasks`の`restart`および`service`値を尊重するようになりました、Postgres、repmgr再起動、スイッチオーバー、レプリカファイナル、rsyslog、およびOpenVPN以前は、 `restart`または`service`タスクを除外するユーザーは、展開中にこれらのエリアで意図しない再起動が発生する可能性がありました。この変更により、すべての再起動およびダイレクトサービス操作が一貫してガードされるため、excluded_tasksはそれらを確実に抑制します。

`tpaexec reconfigure`が--bdr-package-versionを受け入れられるようになりました。 tpaexec reconfigureは、 BDR-Always-ON、PGD-Always-ON、PGD-X、およびPGD-Sクラスターで--bdr-package-versionを受け入れ、config.ymlに値を記録し、バージョンゲートされた構成オプションを適用するようになりました選択したバージョンには以下が必要です。現在、このようなオプションはPGD 5.5+のdefault_pgd_proxy_optionsのread_listen_portであり、PGD 5.5クラスターの`tpaexec configure`の動作と一致します。新しいロジックは、 BDR-Always-ON → PGD-Always-ONおよびPGD-Always-ON → PGD-Xアーキテクチャ変更の require()としても実行されるため、これらのアップグレードパスはバージョンゲートされたオプションを選択します。 -bdr-package-versionが提供されます。

TPAは、PGD 5マイナーアップグレードのenable_proxy_monitoringをサポートするようになりました。 Enable_proxy_monitoringオプションは、 PGD-Always-ONクラスターでのPGD 5マイナーバージョンのアップグレード中に機能するようになりました。以前は、プロキシモニタリングは、 BDR 4からPGD 5メジャーアップグレード中にのみサポートされていました。プロキシモニタは、有効にすると、アップグレードプロセス全体でpgd-proxyエンドポイントを介した接続の可用性を追跡し、中断が報告されます。

の変更#

Description

Addresses

upgrade_legacy.ymlを専用のupgrade_major_4to5.ymlプレイブックに置き換えました。 BDR 4→5メジャーアップグレードロジックは、モノリシックupgrade_legacy.ymlから専用のプレイブックに抽出されました。これにより、すべての条件分岐、フェールオーバーマネージャーとしてのharpのハードコーディング、およびバージョン4としてのupgrade_fromを削除することにより、アップグレードパスが簡素化されます。現在、孤立したupgrade_legacy.ymlファイルは、PGD-Always-ONおよびLightweightアーキテクチャから削除されています。

BDR 5.xマイナーアップグレード用の専用のupgrade_minor_5.ymlプレイブックを追加しました。この新しいプレイブックは、すべてのBDR 5.xマイナーアップグレードを処理します。これは、モノリシックupgrade_legacy.ymlに以前に埋め込まれた関連ロジックを使用し、アップグレードプロセスのメンテナンスが簡単になります。

TPAは、空の--teamおよび--ownerをpemworkerに渡さなくなりました。 PostgresサーバーをPEMに登録する際、 monitoring_team`または`monitoring_server_owner`変数が設定されていない場合、TPAは以前に--team ""および--owner ""`を`pemworker --register-server`に渡していました。以前のPEMバージョンは、これらの空の文字列をオプションを省略するのと同等のものとして扱いましたが、PEM 10.5ではCLI検証を強化し、空の文字列を拒否するため、登録タスクが失敗します。 TPAは、対応する変数が設定されていない場合にこれらのフラグを完全に省略するようになったため、構成の変更を必要とせずにPEM 10.5に対するサーバー登録が成功します。

AAPでカスタムプレイブックを実行する方法を文書化しました。 AAPユーザードキュメントでは、カスタムプレイブックをクラスターに追加し、`commands/`サブディレクトリ規約とAAPのDuplicate Templateアクションを使用して、AAPを介して実行する方法を説明するようになりました。

不足しているフラグをtpaexecヘルプ出力に追加しました。 'tpaexec help'には、実際にサポートされているいくつかのフラグがありませんでした。この変更により、これらのフラグがヘルプ出力に追加されます。

TPAは、展開の開始時にEPASクラスターでpgauditを拒否するようになりました。 EPASクラスターの`extra_postgres_extensions`に`pgaudit`を含めると、Postgresのスタートアップに遅くに失敗する展開が発生していました。これは、EPASでpgauditがロード可能ではないためです。 TPAは、展開の開始時にこの組み合わせを検出し、失敗して、EPASのビルトイン監査機能を推奨するメッセージを表示します。

{stop,start,list}コンテナをtpaexec --help出力に追加しました。 tpaexecでDockerコンテナを管理するための既に実装されたオプションは、ドキュメントでは紹介されていますが、 `tpaexec --help`の出力ではありません。この変更により、`tpaexec --help`コマンドにこれらのコマンドの動作の簡単な概要が含まれるようになりました。

バグ修正#

Description

Addresses

BDR 4からBDR 5へのアップグレード中に、 tpaexec reconfigureがpostgres_distributedを追加しない問題を修正しました。 `tpaexec reconfigure`コマンドは、 BDR 4からBDR 5にアップグレードする際に、 `postgres_distributed`リポジトリを追加しませんでした。これにより、新しいBDR 5パッケージをダウンロードしようとすると失敗します。この修正により、`postgres_distributed`リポジトリが構成に含まれるようになります。

スタンバイノードがBDRプライマリ候補に昇格できる問題を修正しました。展開中にスタンバイノードがBDRプライマリ候補として選択される場合がある問題が見つかり、一部のクラスターシナリオたとえば、スタンバイノードを介してBDRノードグループに参加する場合など、意図しない結果を引き起こす可能性があります。この修正により、スタンバイノードが潜在的なBDRプライマリ候補のリストから除外されます。

EDBPGEおよびEPASでパトローニをフィーチャーするとSLES 15の展開が失敗する問題を修正しました。 EDBPGE / EPAS PostgreSQLフレーバーでフェールオーバーマネージャーとしてpatroniを選択した場合、etcd関連パッケージのインストールに必要なモジュールが欠落しており、展開が正しく機能するようにいくつかの追加の調整が必要でした。この修正により、パトロニをフェールオーバーマネージャーとしてSLES 15に展開するときに、必要なパッケージがインストールされるようになり、いくつかの軽微な調整が行われます。

PEMエージェント<9.6を要求すると展開が失敗する問題を修正しました。 TPAは`pemworker --enable-probe`オプションを使用して、必要に応じてEFMプローブを有効にします。ただし、このオプションはPEM 9.6より前には存在しないため、呼び出そうとするとエラーが発生します。この修正では、このタスクにバージョンチェックを追加します。エージェントバージョンが9.6未満の場合、スキップされることを意味します。

pgd-cliがアップグレードされていない場合にpgd-cliタスクが実行される問題を修正しました。 postgresのみのアップグレードデフォルト中に、pgd-cli診断出力をログに記録し、書き込みリーダー選択を待機するタスクは、pgd-cliがその実行の一部としてアップグレードされていない場合でも、常に最初のBDRプライマリで実行されました。これにより、古いpgd-cliバイナリがそのサブコマンドをサポートしていないため、「unknownコマンドshow-groups」でアップグレードが失敗しました。 pgdcliまたはすべてのコンポーネントがアップグレードに含まれない限り、両方のタスクがスキップされるようになりました。

デフォルトのAWS AMIを現在利用可能なイメージに更新しました。公式にサポートされているプラットフォーム用に`tpaexec configure`が選択するデフォルトのAWS AMIが、現在利用可能なイメージに更新されました。以前は、いくつかのAMI特にUbuntu 22.04、Ubuntu 24.04、RHEL 8.10、およびSLES 15 SP7がベンダーによって登録解除されており、これらのプラットフォームの新しいクラスターで`tpaexec provision`が失敗する原因となっていました。 9.5は現在のマイナーでなくなり、更新された9.5 AMIは公開されないため、RHEL 9およびRocky 9もマイナーバージョン9.5から9.7に移行します。

TPAは、インストールされたBDR/PGDパッケージからbdr_version_numを自動的に取得するようになりました。 TPAはbdr_version_numを使用して、 CAMO構成に関する正確な決定を下します。以前は、この値は実行中のデータベースを照会することによってのみ取得されていたため、初期展開Postgresがまだ実行されていない場合、 CAMO構成の一部を正しくレンダリングできず、ユーザーは回避策としてconfig.ymlでbdr_version_numを手動で設定する必要がありました。 TPAは、各ノードにインストールされているBDRまたはPGDパッケージのバージョンからbdr_version_numを取得するようになったため、手動設定は必要ありません。 config.ymlで設定された値は引き続き優先され、データベースが実行されると、 bdr.bdr_version_num()によって報告される正確な値が権限のあるままです。

PGD 6マイナーアップグレードのアップグレード後のヘルスチェックを安定させました。 PGD 6マイナーアップグレードの最後のローリングリスタートの後、 BDRレプリケーションスロットは、更新されたばかりのノードと再ハンドシェイクしている間、一時的に非アクティブなままになる場合があります。アップグレード後の`pgd cluster show --health`チェックは、その期間に起動され、偽の「レプリケーションスロットクリティカル」障害を報告する可能性があります。 TPAは、厳密なヘルスチェックを実行する前に、すべてのスロットがアクティブになるのを待機する最大2分間`bdr.group_replslots_details`をポーリングするようになりました。ウィンドウが使い果たされた場合でも、ヘルスチェックは実行されるため、本物の問題は引き続き報告されます。

カスタムrc-localサービスの作成に関する問題を修正しました。 TPAはカスタムsystemdサービスファイルを作成して、デフォルトでサポートしていないディストリビューションで起動時にrc-localスクリプトが実行されるようにします。この修正では、サービスファイルの場所を変更して規約に従い、以前に選択したパスで発生する可能性のある親フォルダーの欠落による障害を回避します。この修正により、このサービスファイル作成タスクは実際に必要な場合にのみ適用されます。

TPAは、アーキテクチャに基づいてPostgres拡張を`pgextended`および`edbpge`に正規化するようになりました。アーキテクチャに基づいてPostgres拡張フレーバーを正規化するための修正が導入されました。 tpaexec configure --pgextended、--edbpge、--edb-postgres-extended、または --postgres-flavour pgextended/edbpge を介してPostgres拡張バリアントを選択すると、 BDR-Always-ONまたは古いアーキテクチャが`pgextended`に正規化されますが、新しいアーキテクチャは`edbpge`に正規化されます。互換性のないアーキテクチャに`pgextended`フレーバークラスターを展開しようとするとエラーが発生し、構成ミスを防ぎます。

read_listen_portが5.5より前のBDRバージョンの構成に追加された問題を修正しました。 tpaexec manageは、古いBDRバージョンの場合でもread_listen_portをdefault_pgd_proxy_optionsに追加しました。 PGD 5.5以降にアップグレードするときに欠落しているread_listen_portをキャッチするために、展開時アサーションも追加されました。

TPAは、構成時に無効なクラスター名を拒否するようになりました。以前は、`tpaexec configure`は、ピリオドなどの文字を含むクラスター名を受け入れましたたとえば、クラスターディレクトリ名に`v1.1.0-rc.1`のようなバージョン文字列が埋め込まれている場合。構成は正常に書き込まれましたが、クラスター名が必要なパターン`^[_a-zA-Z0-9-]+$`と一致しなかったため、後の`tpaexec provision`は致命的なアサーションで失敗しました。 `tpaexec configure`は、クラスターディレクトリが作成される前に同じチェックを前もって適用し、無効な名前を拒否するようになりました。そのため、問題は数ステップ後ではなく、すぐに報告されます。

Playbookをアップグレードすると、pgrepの代わりにsystemctlが使用されるようになりました。メジャーおよびマイナーPGDアップグレードプレイブックは`pgrep`を使用して、ノードでharp-proxyまたはharp-managerがまだ実行されているかどうかを判断します。 procpsがインストールされていないホストでは、これらのチェックのうち2つは、「バイナリがありません」を「プロセスが実行されていません」と静かに誤読しました。 BDR 4→5アップグレードは、harp-managerを停止する前に`harpctl unmanage cluster`をスキップし、PGD 5マイナーアップグレードは間違ったプロキシを実行しました健康診断。チェックでは、`systemctl is-active --quiet`を使用するようになりました。これは、すべてのディストリビューションTPAで動作し、権限のあるサービス状態をサポートおよび反映します。

TPAは、EPASクラスターでのCISコンプライアンスからpgauditを省略するようになりました。以前は、 `tpaexec configure --compliance cis`は無条件に`pgaudit`を`extra_postgres_extensions`に追加しました。これにより、監査ログが組み込まれているEPASでの起動障害が発生したため、EPASクラスターでは`pgaudit`が省略されます。

pgbouncerとpgd-proxyがリッスンポートを共有する場合、TPAは展開に失敗するようになりました。インスタンスのロールリストに`pgbouncer`と`pgd-proxy`の両方があり、両方のサービスが同じポートデフォルトの6432でリッスンするように構成されている場合、一方のみがバインドできます。通常、pgBouncerがレースに勝ち、pgd-proxyは障害が発生した状態のままになりましたが、TPAの展開は成功を返しました。構成ミスは、最初のアップグレード中に、pgd-proxyの代わりにpgBouncerに接続するTLS保護テストからの`FATAL: SSL required`エラーとしてのみ可視化されました。 TPAは、影響を受けるホストと関連する2つの変数`pgbouncer_port`および`pgd_proxy_options.listen_port`を名前付けた明確なメッセージで、展開時にこの構成を拒否するようになりました。 pgbouncerとpgd-proxyを共同ホストするユーザーは、2つのリスナーが衝突しないように、いずれか1つを`config.yml`でデフォルト以外の値に設定する必要があります。

TPAは、4to5アップグレード中にpgd-proxyノードにpgd-cliをインストールするようになりました。 BDR-Always-ONからPGD-Always-ONへのアップグレードは、pgd-proxyロールを以前のharp-プロキシノードに追加しますが、アップグレード中にpgd-cliはこれらのノードにインストールされません。アップグレード後診断は、「そのようなファイルまたはディレクトリはありません」で失敗しました。 pgdcli-upgrade再生はpgd-プロキシホストもターゲットとするようになったため、診断の実行時にpgd-cliが配置されます。

自動監視ノード追加が、偶数データノードを含むPGD-Xクラスターで機能しない問題を修正しました。偶数の`--data-nodes-per-location`でPGD-Xクラスターを構成する場合、tpaexec configure`は各場所に監視ノードを正しく追加するようになりました。これにより、ユーザーが--add-witness-node-per-location`を明示的に渡すことなくRaftコンセンサスを確立できます。この動作は、 PGD-Always-ONアーキテクチャおよびPGD-Xの文書化された動作と一致するようになりました。 tpaexec configure`は、2より小さい--data-nodes-per-location`値も拒否するようになりました。これにより、以前はデータノードのない無効なクラスターが生成されました。

59694

TPAには、PEMサーバーバージョン10.4.0以降の正しいmod_wsgiモジュールが含まれるようになりました。この変更により、以前のバージョンの既存の動作を保持しながら、正しいmod_wsgiモジュールがPEMサーバーバージョン10.4.0以降に含まれることが保証されます。

TPAには、SLES 15にEPASを展開するための追加モジュールが含まれるようになりました。 SLES 15クラスターを展開する場合、EPASとPEMインストールの両方の初期システム登録の一部としてPackageHub登録が実行されるようになりました。さらに、libclang13などの依存関係をインストールするために、EPAS展開で2つの新しいモジュールsle-module-desktop-applicationsおよびsle-module-development-toolsが有効になりました。

TPAは、古いクラスターディレクトリにswitch2cm.ymlリンクを自動作成するようになりました。 `tpaexec switch2cm`は、クラスターディレクトリに`architectures/PGD-Always-ON/commands/switch2cm.yml`へのリンクがなかったため、 `switch2cm`コマンドより前のTPAリリースで構成されたクラスターで「the playbook:command/switch2cm.ymlが見つかりませんでした」で失敗しました。 `tpaexec switch2cm`は、リンクが見つからない場合に`tpaexec relink`を自動的に呼び出すようになりました。これは、 `tpaexec upgrade`が独自のコマンドリンクに対して既に持っていた動作と一致します。

アップグレード中にノード2+でHARPマネージャーのシンボリックリンクの作成が失敗する問題を修正しました。 edbpgeへのローリングアップグレード中に、 HARPマネージャーがデータベースに接続するための/var/run/postgresql/.s.PGSQL.<port>にシンボリックリンクを作成するタスクは、最初の「変換を拒否」の後、すべてのノードで失敗しますファイルからシンボリックリンクへ」。宛先パスは、アップグレード前のpostgresフレーバー移行またはクリーンでない停止から残された実際のソケットファイルを保持する可能性があります。影響を受けるすべてのアップグレードPlaybookのシンボリックリンクタスクにforce:trueを追加すると、そのパスの以前の状態に関係なく、シンボリックリンクが正しく作成されます。

アップグレード時のBDRレプリケーションスロット間の再試行ロジックを導入しました。 BDRクラスターでpostgresqlパッケージバージョンをアップグレードする場合、レプリケーションスロットの再接続に数秒かかる場合があり、リカバリプロセスに十分な時間が割り当てられていないため、アップグレードプロセスで終了エラーが発生する場合があります。この修正では、アップグレードプロセスのヘルスチェックに再試行ロジックを追加して、スロットが回復する時間を確保し、タイミング関連の障害を回避します。

--location-namesがアーキテクチャの要件と一致しない場合、TPAは明確なエラーを報告するようになりました。以前は、 --location-names`に間違った数の名前たとえば、2つ必要な`bronze`レイアウトを使用する`BDR-Always-ON`クラスターの単一のロケーションを提供すると、`tpaexec configure`が未処理のPythonトレースバックでアボートしていました。 `tpaexec configure`は、指定されたロケーション名と、選択されたアーキテクチャとレイアウトが実際に必要なロケーションの数と比較し、それらが異なる場合は明確なエラーをレポートするようになりました。この変更は、`M1、BDR-Always-ON、および`PGD-Always-ON`アーキテクチャに適用されます。

PGD-Xが--hostnames-fromで多すぎるホスト名を要求する問題を修正しました。 --hostnames-fromを使用してPGD-Xクラスターを構成すると、指定されたファイルが16未満の名前を保持するときは常に、クラスターがほんの一握りのみを必要とする場合でも、「…と一致するN/16の名前のみが見つかりました」で失敗していました。基になるPGD-Xアーキテクチャは、ビルドするインスタンスの実数ロケーションごとのデータ+監視+バーマンノード、および要求に応じてオプションの監視専用ロケーションとpemサーバーを計算するようになったため、 --hostnames-fromは正しく受け入れます。ファイルのサイズが大きくなり、16エントリにパディングする必要はなくなりました。

CAMO構成が誤ってconfig.ymlに追加される問題を修正しました。 --enable-camoでCAMOを明示的に有効にせずに--data-nodes-per-location 2でPGD-Xクラスターを構成すると、生成されたconfig.ymlには、 CAMOコミットスコープとパートナーの割り当てが誤って含まれます。これにより、予期しないCAMO構成が要求しなかったクラスターに適用されます。 CAMO構成は、 --enable-camoが明示的にtpaexecconfigureに渡された場合にのみ生成されるようになりました。

59694

PGD 5/6マイナーおよび5-6メジャーアップグレードが時折ノードをフェンスされたままにする問題を修正しました。ループの以前にフェンスされたノードがアンフェンスされないため、ノードごとのアップグレード中に、「書き込みリーダー選択の完了を待機する」タスクがタイムアウトになる場合があります。 unfenceステップは、常にノードの更新された状態を参照するとはせず、誤ってスキップされ、ノードがフェンスされたままになります。 TPAは、ノードがRaftコンセンサスに再参加するのを待機し、アンフェンシングする前にその状態を更新するため、ノードは確実にアンフェンスされ、アップグレードを続行できます。

tpaexec configure`の--primary-location`のエラー出力を改善しました。プライマリロケーションがロケーションのリストで見つからない場合、 --primary-location`および--location-names`引数間の引数解析ロジックのエラーにより、ビルトインPythonエラーがスローされました。これは、TPAではないため、ユーザーの誤解を招く可能性があります関連のエラー。この修正では、提供されたプライマリ場所と既知の場所のリスト間の不一致を適切に処理し、混乱を招くエラーメッセージを回避します。

--overrides-fromが指定されたときにtpaexecconfigureがクラッシュする問題を修正しました。 `--overrides-from <file>`とともに`tpaexec configure`を実行すると、「tpaexec configureの実行中にエラーが発生しました。名前'reduce'は定義されていません」で中止され、クラスターディレクトリは生成されません。 `tpaexec configure --overrides-from`は正常に完了し、指定されたYAMLファイルの値は、文書化されているように、生成されたクラスター構成にマージされます。

`tpaexec switch2cm`は、 ansible_userがrootでない場合に動作するようになりました。 PGD-Always-ONの3つのプレイ switch2cmコマンドはプレイレベルになることを宣言していないため、コマンドはansible_userがrootの場合にのみ機能します。非ルートのansible_userでは、 /pgdata/data/conf.dで「Permission denied」で失敗しました。これらのプレイは明示的にルートになり、PGD-Always-ONの他の場所で使用されるパターンと一致します。タスクごとは、postgresユーザーとして実行されるSQLクエリのオーバーライドになります。影響を受けません。

TPAは、PostgreSQL 18+ PGDクラスターのmax_active_replication_originsを構成するようになりました。 TPAは、「3 *number_of_nodes + 3」を使用して、PostgreSQL 18以降でPGDクラスターのmax_active_replication_originsパラメーターを設定するようになりました。これは、EDB PGDドキュメントで推奨されている最小「ピアノードごとに3つのオリジン」を超える安全マージン式です。これにより、マルチノードクラスターに対してデフォルト値が低すぎることによって発生するPGDノード参加の失敗が防止されます。

TPAは、バーマン構成のバックアップサーバーごとにpath_prefixを設定するようになりました。 Barmanのpath_prefixは、以前はbarmanホスト自分自身のpostgresバイナリディレクトリを使用して、barman.confのグローバル値としてのみ設定されていました。これにより、混合バージョンのシナリオローリングアップグレード中、またはバーマンホストがバックアップするノードとは異なるPostgreSQLメジャーバージョンを実行している場合に、不正な動作が発生しました。 path_prefixも、バックアップサーバーごとに/etc/barman.d/<backup>.confに書き込まれ、バックアップされたノード自分自身のpostgres_bin_dirから解決されます。これにより、barmanは、バックアップする各ノードに正しいクライアントバイナリを使用することが保証されます。 barman.confのグローバルpath_prefixは変更されず、同じバージョンのシナリオのデフォルトとして機能し続けます。バックアップノードのPostgreSQLバージョンがbarmanホストのバージョンと異なる場合、一致するクライアントパッケージがbarmanホストに自動的にインストールされるように、サーバーごとのpath_prefixが実際のバイナリに解決されます。 barmanホストには、追加のPostgreSQLバージョンのリポジトリアクセスが必要です通常はEDBエンタープライズリポジトリの場合。インスタンスごとの明示的なオーバーライドは、config.ymlのノードのvarsでbarman_path_prefixを設定することにより使用できます。

非推奨#

Description

Addresses

PGD-Xの非推奨の`--cohost-proxies`および`--add-proxy-nodes-per-location`構成フラグを削除しました。 PGD-Xの--cohost-proxiesおよび--add-proxy-nodes-per-locationフラグは削除され、PGD-Xアーキテクチャの`tpaexec configure`の有効なオプションではなくなります。 PGD 6では、すべてのプロキシがコホストされるため、両方のオプションが時代遅れになります。
目次