Known issues

Known issues#

このページには、TPAの現在のバージョンに影響を与える既知の問題をリストしています。既知の場合、各問題の回避策が提供されます。

複数のロケーションを持つEFMクラスターにロケーション間のHBAルールがありません TPA-1247#

詳細#

複数の場所でEFMクラスターを展開し、1つのノードでefm cluster-status コマンドを実行すると、FATAL: password authentication failed for user "efm" が、ノードと同じ場所にないすべてのノードの Promote Status セクションに表示されることがわかります。コマンドが実行されました。

これは、TPAが、EFMユーザーがある場所のノードから別の場所のノードに接続するために必要なHBAルールを追加できないために発生します。

回避策#

postgres_hba_settings クラスター変数を使用して、efm ユーザーおよびreplication ユーザーが任意のノードから他のノードに接続できるように、ノードごとに1つのHBAルールを指定します。例

postgres_hba_settings:
  - hostssl all efm 192.168.57.12/32 md5
  - hostssl all efm 192.168.57.13/32 md5
  - hostssl all efm 192.168.58.11/32 md5
  - hostssl all efm 192.168.58.12/32 md5
  - hostssl all efm 192.168.58.13/32 md5

  - hostssl replication replication 192.168.57.12/32 md5
  - hostssl replication replication 192.168.57.13/32 md5
  - hostssl replication replication 192.168.58.11/32 md5
  - hostssl replication replication 192.168.58.12/32 md5
  - hostssl replication replication 192.168.58.13/32 md5

TPA 23.34以前で展開されたPGDクラスターにはprimary_slot_name設定があり、bdr_init_physicalが動作しない TPA-1229#

詳細#

TPA 23.35は、EFMで使用するレプリケーションスロット名がPGDクラスターでprimary_slot_name として誤って設定される問題を解決しました。 TPA 23.35以降で展開されたクラスターには、この問題は発生しません。ただし、以前のバージョンで展開された既存のクラスターは、新しいTPAバージョンで展開が実行された後でも、誤ったprimary_slot_name 設定を保持します。

この不正なprimary_slot_name の影響は、 bdr_init_physicalを使用してクラスターに新しいノードを追加またはノードをリビルドしようとすると、Waiting for PostgreSQL to accept connections... でハングし、ログに致命的エラーreplication slot ... does not exist が表示されることです。

回避策#

ファイル/opt/postgres/data/conf.d/8901-primary_slot_name.conf を削除し、Postgresをリロードすることにより、クラスター内の各Postgresノードからこの誤った設定を手動で削除できます。 TPA 23.35以降を使用している限り、復元されることはありません。

forward_ssh_agent: true を使用したクラスターでのSSH構成テンプレートエラー#

詳細#

TPA 23.43は、クラスターディレクトリのssh_configファイルのテンプレートを変更し、forward_ssh_agent がTrueに設定されている場合、生成された構成ファイルが無効になるバグを導入しました。この設定のデフォルトはFalseで、通常はテスト用のソースコードからクラスターのコンポーネントをインストールする場合にのみTrueに設定されます。

回避策#

tpaexec provision を実行してssh_configファイルを生成した後、テキストエディタでファイルを編集します。 IdentitiesOnly yes ForwardAgent yes を読み取る行、通常はファイルの7行目を見つけ、最初の「yes」の後に改行を追加して2行に分割します。ファイルはtpaexec provision によって上書きされるため、プロビジョニング後にconfig.ymlに変更を行った場合に再編集する必要があります。

pemagent_registration_opts が提供するPEMエージェント登録オプションはagent.cfg に反映されないため、有効になりません TPA-1376#

詳細#

pemagent_registration_opts オプションは、PEMエージェントの登録中に追加のコマンドラインオプションをpemworkerユーティリティに渡すために使用されます。これらのオプションの一部は登録の即時行為に影響を与えるもの、一部はPEMデータベースに書き込まれるデータに影響を与えるもの、その他はエージェントの動作を決定するために使用される生成されたagent.cfg ファイルの内容に影響を与えるものです。 TPAの現在の実装では、 agent.cfg ファイルはテンプレートバージョンで登録された直後に上書きされます。つまり、 pemagent_registration_opts の結果としてこのファイルに加えられた変更は失われます。

回避策#

指定したオプションがagent.cfg と相互作用しないことが確認できる場合を除き、 pemagent_registration_opts の使用は避けてください。デプロイ後フックを使用して、必要な変更をagent.cfg に適用します。

TPAを使用して展開すると、PEM 10.4.x Webアプリケーションに「内部サーバーエラー」が表示される TPA-1415#

詳細#

PEM 10.4は、ほとんどのオペレーティングシステムで以前のPEMバージョンより新しいPythonバージョンを使用します。 TPAはPEMのパッケージ依存関係であるため、必要なPythonバージョンをインストールしますが、以前のバージョンのmod_wsgi モジュールをインストールするため、Webアプリケーションを実行できません。

回避策#

最も完全な回避策は、必要なmod_wsgi パッケージをPEMサーバーインスタンスに明示的に追加することです。必要なパッケージは

PEM documentation で見つかります。 RHEL 9の例

instances:
...

- name: pem-server
  ...
  packages:
    RedHat:
    - edb-python312-mod-wsgi
目次