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`` を追加して、 :ref:`postgres_conf_settings ` を作成しました。 オプション3が自己文書でポータブルであるという事実を除き、方法1または2によって行われた変更を調整するための差し迫った運用上の理由はありません。 破壊的な変更をブロックする ^^^^^^^^^^^^^^^^^^^^^^^^^^ ``config.yml`` 間のより根本的な不一致を作成する変更は、TPAがオペレーションの実行をブロックする可能性があります。たとえば、ベアメタルクラスター内のノードを物理的に削除すると、TPAによるそのノードへの接続は失敗します。つまり、ほとんどのTPA操作はエラーで終了し、この違いを調整するまでTPAでクラスターを管理できません。 。 構成変更を調整する方法 ---------------------- 通常、リコンシリエーションプロセスには、クラスターの現在の状態を記述するように\ ``config.yml`` を変更し、\ ``tpaexec deploy`` を実行することが含まれます。 例 PGDノードの分割 ^^^^^^^^^^^^^^^^^^ ベアアーキテクチャと次のようなconfigureコマンドを使用して、最小限のPGDクラスターを展開します。 .. code:: shell 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にノードが分離されたことを伝えるメタデータを上書きしないためです。 .. Note:: TPA、そして実際にPGD自分自身には、'parted'状態でノードを初期化するメカニズムがないため、 `config.yml` をこのクラスター状態と調整することはできません。原則として、TPAを使用してこの分割されたクラスターを継続できますが、これはお勧めできません。ほとんどの場合、ノードの完全な削除と`config.yaml` の調整を続行することができます。 .. :: ### 例 PGDノードを完全に削除する 前の例では、PGDクラスターからノードを分離しましたが、ノード自分自身は無傷のままで、実行可能だが調整不能な状態でTPAによって管理されています。 ノードを完全に停止するには、\ ``node-2`` に対応するサーバーの電源をオフにするだけで安全です。この段階で\ ``deploy`` を実行しようとすると、サーバーに到達できず早期に失敗します。 ``config.yml`` のこの変更を調整するには、\ ``node-2`` に対応する\ ``instances`` の下のエントリーを削除するだけです。これは次のようになります。 .. code:: yaml - 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`` を参照するメタデータがまだあります。これは、クラスター機能に影響を与えないため、デフォルトでは削除されません。 .. Note:: `config.yml` から削除した後、元の`node-2` をクラスターに参加させたい場合は、`config.yml` の削除された行を復元し、Postgresを停止し、そのノードの`PGDATA` ディレクトリを削除して、`tpaexec deploy` を繰り返すことにより実行できます。上記のように、TPAは、対応するエントリが`config.yml` から削除されても、既存のデータベースを削除しないため、このアクションを手動で実行する必要があります。 .. :: ### 例 スーパーユーザーパスワードの変更 TPAは、スーパーユーザーのパスワードを自動的に生成します。これは、 ``tpaexec show-password `` を使用して表示できます。パスワードを手動で変更する場合たとえば、 psqlの\ ``/password`` コマンドを使用すると、次に\ ``tpaexec deploy`` が実行された後、パスワードがTPAによって設定されたものに戻っていることがわかります。 TPAを介して変更を行い、\ ``tpaexec deploy`` の実行全体で持続させるには、 ``tpaexec store-password `` コマンドを使用してパスワードを指定し、\ ``tpaexec deploy`` を実行する必要があります。これは、TPAを通じて作成された他のユーザーにも適用されます。 例拡張機能の追加または削除 ^^^^^^^^^^^^^^^^^^^^^^^^^^ 単純なシングルノードクラスターは、次の\ ``config.yml`` を使用して展開できます。 .. code:: yaml - -- 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を使用して拡張機能を追加することをお勧めします。 .. code:: yaml 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`` を調整するには、前に追加した行を削除するだけです。 .. Note:: 前述のように、TPAは破壊的な変更を受け入れません。したがって、`config.yml` から行を削除するだけでは拡張機能は削除されません。この操作を手動で実行し、変更を調整する必要があります。 !!!