Reconciling changes made outside of TPA

Reconciling changes made outside of TPA#

TPA構成を変更して実行されないTPA作成クラスターへの変更は、config.yml に保存されません。これは、クラスターにTPA構成で再作成できない変更が含まれることを意味します。

このページでは、TPAで構成が管理される方法と、構成を変更するための推奨される方法を示します。次に、作成する戦略を確認し、クラスターに手動変更を加えた結果を調整します。

手動で構成を変更する必要があるのはなぜですか?#

TPAの外部で構成を変更する必要がある最も一般的なシナリオは、実行している操作がTPAでサポートされていない場合です。このような操作で最も一般的な2つは、ノードの削除などの破壊的な変更と、Postgresのメジャーバージョンのアップグレードです。

破壊的な変更#

一般に、TPAは、クラスターの以前に展開された要素を削除しません。これらはconfig.yml から削除される場合でも。厳密な宣言型システムは、宣言と一致するようにデプロイされたアーティファクトを常に変更する必要があるため、これは人々を驚かせる場合があります。ただし、実稼働データベースに破壊的な変更を行うと、重大な結果を招く可能性があるため、サポートしないことを選択しました。

メジャーバージョンのPostgresのアップグレード#

TPAは、Postgresのメジャーバージョンのアップグレードを実行するための自動メカニズムをまだ提供していません。したがって、既存のクラスターでインプレースアップグレードを実行する必要がある場合、これは pg_upgradeや pgd node upgrade などの他のツールを使用して実行する必要があります。

変更がリコンサイルされていない場合、何が起こりますか?#

未リコンサイルの変更に関する一般的な問題は、既存のconfig.yml を使用して新しいクラスターを展開する場合、または問題を再現するためにconfig.yml をEDBサポートに提供する場合、元のクラスターと一致しないことです。さらに、将来的にTPAを使用してそのクラスターを管理する場合、操作上の問題が発生する可能性があります。

未調整の変更の運用への影響は、変更の性質によって異なります。特に変更が破壊的かどうか、および変更がエラーを発生させるかconfig.yml のデータを無効にすることによりTPAの実行をブロックするかどうか。

非破壊的、非ブロッキングな変更#

多くの場合、追加的な変更はすぐに運用上の問題なく対応されます。ユーザーを手動で追加することを検討します。新しいユーザーは存在し続けますが、TPAに関する問題はまったく発生しません。 TPAを介してユーザーを管理する場合、config.yml で宣言できますが、手動追加ユーザーの存在は操作上の問題を発生させません。

一部の手動追加は、より微妙な効果を持つ場合があります。手動で追加された拡張機能の例を考えます。 TPAは破壊的な変更を行わないため、次回tpaexec deploy が実行されたときに拡張機能は削除されません。 ただし、 、新しい拡張機能に対応するようにPostgres構成を変更した場合、TPAでサポートされているメカニズム以下を参照していない場合、これらは上書きされる可能性があります。

さらに、TPAは手動変更を反映するようにconfig.yml ファイルを変更しようとせず、新しい拡張機能はtpaexec upgrade から省略されるため、クラスターに互換性のないソフトウェアバージョンが存在する可能性があります。

破壊的なノンブロッキングの変更#

簡単に検出され、TPAのオペレーションをブロックしない破壊的な変更は、次回tpaexec deploy が実行されたときに単に元に戻されます。拡張機能を手動で削除することを検討します。 TPAの観点から、この状況は、ユーザーがconfig.yml ファイルに拡張機能を追加し、deployを実行することと区別できません。そのため、TPAは、クラスターとconfig.yml が調整されるように拡張機能を追加しますが、ユーザーが意図したものとは逆の方法です。

同様に、構成パラメーターに手動で加えられた変更は、次の場合を除き、元に戻されます。

  1. 手動編集用に予約されたconf.d/9999-override.conf ファイルで作成されます。

  2. ALTER SYSTEM SQLを使用して作成されました。または

  3. postgres_conf_settings を追加して、 postgres_conf_settings を作成しました。

オプション3が自己文書でポータブルであるという事実を除き、方法1または2によって行われた変更を調整するための差し迫った運用上の理由はありません。

破壊的な変更をブロックする#

config.yml 間のより根本的な不一致を作成する変更は、TPAがオペレーションの実行をブロックする可能性があります。たとえば、ベアメタルクラスター内のノードを物理的に削除すると、TPAによるそのノードへの接続は失敗します。つまり、ほとんどのTPA操作はエラーで終了し、この違いを調整するまでTPAでクラスターを管理できません。 。

構成変更を調整する方法#

通常、リコンシリエーションプロセスには、クラスターの現在の状態を記述するようにconfig.yml を変更し、tpaexec deploy を実行することが含まれます。

例 PGDノードの分割#

ベアアーキテクチャと次のようなconfigureコマンドを使用して、最小限のPGDクラスターを展開します。

tpaexec configure mycluster \
- a PGD-Always-ON \
- -platform bare \
- -edbpge 15 \
- -location-names a \
- -pgd-proxy-routing local

次のSQLを使用してノードを分割します。これは、任意のノードから実行できます。

select * from bdr.part_node(‘node-2’);

deploy を再実行します。エラーは発生していませんが、ノードはまだ分離されたままであることに注意してください。これは、任意のノードでコマンドpgd show-nodes を使用して確認できます。これは、TPAがPGDにノードが分離されたことを伝えるメタデータを上書きしないためです。

!!!注

TPA、そして実際にPGD自分自身には、’parted’状態でノードを初期化するメカニズムがないため、 config.yml をこのクラスター状態と調整することはできません。原則として、TPAを使用してこの分割されたクラスターを継続できますが、これはお勧めできません。ほとんどの場合、ノードの完全な削除とconfig.yaml の調整を続行することができます。

前の例では、PGDクラスターからノードを分離しましたが、ノード自分自身は無傷のままで、実行可能だが調整不能な状態でTPAによって管理されています。

ノードを完全に停止するには、node-2 に対応するサーバーの電源をオフにするだけで安全です。この段階でdeploy を実行しようとすると、サーバーに到達できず早期に失敗します。

config.yml のこの変更を調整するには、node-2 に対応するinstances の下のエントリーを削除するだけです。これは次のようになります。

- Name: node-2
  public_ip: 44.201.93.236
  private_ip: 172.31.71.186
  location: a
  node: 2
  role:
  - bdr
  - pgd-proxy
  vars:
    bdr_child_group: a_subgroup
    bdr_node_options:
      route_priority: 100

これで、TPAを使用してこのノードを通常のように管理できるようになりました。元のクラスターには、状態がPARTED であるノードとしてnode-2 を参照するメタデータがまだあります。これは、クラスター機能に影響を与えないため、デフォルトでは削除されません。

!!!注

config.yml から削除した後、元のnode-2 をクラスターに参加させたい場合は、config.yml の削除された行を復元し、Postgresを停止し、そのノードのPGDATA ディレクトリを削除して、tpaexec deploy を繰り返すことにより実行できます。上記のように、TPAは、対応するエントリがconfig.yml から削除されても、既存のデータベースを削除しないため、このアクションを手動で実行する必要があります。

TPAは、スーパーユーザーのパスワードを自動的に生成します。これは、 tpaexec show-password <cluster> <superuser-name> を使用して表示できます。パスワードを手動で変更する場合たとえば、 psqlの/password コマンドを使用すると、次にtpaexec deploy が実行された後、パスワードがTPAによって設定されたものに戻っていることがわかります。 TPAを介して変更を行い、tpaexec deploy の実行全体で持続させるには、 tpaexec store-password <cluster> <superuser-name> コマンドを使用してパスワードを指定し、tpaexec deploy を実行する必要があります。これは、TPAを通じて作成された他のユーザーにも適用されます。

例拡張機能の追加または削除#

単純なシングルノードクラスターは、次のconfig.yml を使用して展開できます。

- --
architecture: M1
cluster_name: singlenode

cluster_vars:
  postgres_flavour: postgresql
  postgres_version: 15
  preferred_python_version: python3

instance_defaults:
  image: tpa/debian:11
  platform: docker
  vars:
    ansible_user: root

instances:

-  Name: nodeone
  node: 1
  role:
  - primary

ノードに接続してapt install postgresql-15-pgvector を実行して、次のSQLコマンドCREATE EXTENSION vector; を実行することにより、pgvector拡張機能を手動で追加できます。これは、 config.yml が以前のようにクラスターを完全に説明しないという事実を超えて、操作上の問題は発生しません。ただし、次のクラスター変数を追加することにより、config.yml を調整するか、実際に単にTPAを使用して拡張機能を追加することをお勧めします。

cluster_vars:
  ...
  extra_postgres_packages:
   common:
   - postgresql-15-pgvector
  extra_postgres_extensions:
  - vector

この構成を追加した後、 SQLコマンドDROP EXTENSION vector; 、次にapt remove postgresql-15-pgvector を実行して、拡張機能を手動で削除できます。ただし、config.yml を調整せずにtpaexec deploy を再度実行すると、拡張機能は再インストールされます。 config.yml を調整するには、前に追加した行を削除するだけです。

!!!注

前述のように、TPAは破壊的な変更を受け入れません。したがって、config.yml から行を削除するだけでは拡張機能は削除されません。この操作を手動で実行し、変更を調整する必要があります。 !!!

目次