pglogical configuration

TPAは、 pglogical v2およびpglogical v3でpglogicalレプリケーションセット(パブリケーション)とサブスクリプションを構成できます。

instances:

- node: 1
  Name: kazoo
  …
  vars:
    publications:
    - type: pglogical
      database: example
      name: some_publication_name
      replication_sets:
      - name: custom_replication_set
        …


- node: 2
  Name: keeper
  vars:
    subscriptions:
    - type: pglogical
      database: example
      name: some_subscription_name
      publication:
        name: some_publication_name
      replication_sets:
        - default
        - default_insert_only
        - custom_replication_set
      …

type: pglogical でパブリケーションまたはサブスクリプションを定義すると、デフォルトでpglogical拡張機能が作成されますが、どのバージョンをインストールするかを決定します(例、 pglogical3のproducts/pglogical3/release リポジトリーにサブスクライブします)。

はじめに

TPAは、 pglogicalを使用してインスタンス間で変更をレプリケートするために必要なすべてを構成でき、 config.ymlの変更に基づいてレプリケーション設定を変更することもできます。

変更を公開するには、 publications にtype: pglogical を使用してエントリーを定義します。これらの変更をサブスクライブするには、上記のように subscriptions に type: pglogical を使用してエントリーを定義します。

Pglogicalには名前付き公開エンティティがありません(組み込みの論理レプリケーションにCREATE PUBLICATION があるという意味で)。 config.ymlのパブリケーションは、レプリケーションセットのコレクションに名前を割り当てるだけで、サブスクリプションはこの名前を使用して目的のプロバイダーを参照できます。

pglogicalレプリケーションを使用するには、パブリッシャーとサブスクライバーの両方に名前付きローカルpglogicalノードが必要です。 TPAは、存在しない場合、pglogical.create_node() でこのノードを作成します。パブリケーションの場合、パブリケーション名がpg論理ノード名として使用されます。特定のデータベースには1つのpglogicalノードしか存在できないため、データベースごとにpublications に1つのエントリのみを含めることができます。

ただし、 pglogicalサブスクリプションには独自の名前があります。 TPAは、指定されたname でサブスクリプションを作成し、インスタンスの名前とサブスクリプションが作成されるデータベースの名前に基づいて、 pglogicalノード名のデフォルト値を使用します。必要に応じて、別のnode_name を指定できます。たとえば、同じデータベースでパブリケーションを構成し、そのデータベース内のすべてのサブスクリプションが同じpglogicalノードを共有する必要があります。

TPAは、構成の基本的な検証を行います。 replication_sets をreplciation_sets と綴った場合、または定義されていないパブリケーションをサブスクライブしようとすると、エラーが指摘されますが、意味のあるパブリケーションとサブスクリプションのセットを指定するのはあなたの責任です。

TPAは、ユーザー、拡張機能、およびデータベースを作成した後、 BDR構成の前にpglogicalを構成します。

postgres_users と postgres_databases を設定してレプリケーション用のデータベースを作成し、 postgres-config-final

pglogicalが構成される前にデータベースにデータを入力します。

出版物

publications のエントリーはname およびdatabase を指定する必要があり、オプションの属性を持つ名前付きreplication_sets のリスト、およびテーブルまたはシーケンス名のリストを指定できます。

publications:

- type: pglogical
  database: example
  name: some_publication_name
  replication_sets:
  - name: default
    replicate_insert: true
    replicate_update: true
    replicate_delete: true
    replicate_truncate: true
    autoadd_tables: false
    autoadd_sequences: false
    autoadd_existing: true
  - name: custom_replication_set
    tables:
    - name: sometable
    - name: "some-schema".othertable
      columns: [a, b, c]
      row_filter: a > 42
      synchronize_data: true
    sequences:
    - name: someseq
      synchronize_data: true
    - name: "some-schema".otherseq

各複製セットは、 replicate_insert や autoadd_existing などのオプションの属性を指定できます。指定された場合、それらはpglogical.create_replication_set() への呼び出しに名前付けパラメーターとして含まれます。それ以外の場合、それらは除外され、レプリケーションセットは代わりにpglogicalのデフォルトで作成されます。

pglogical3のautoadd_* パラメーターを使用してレプリケーションセットに属するリレーションのリストを操作する以外に、テーブルまたはシーケンスのリストを明示的に指定することもできます。各リレーションの名前はスキーマ修飾でき(非修飾名はpublic にあると想定されます)、上記のように、エントリにはrow_filter (テーブルのみ)またはsynchronize_data などのオプションの属性を含めることができます。

サブスクリプション

subscriptions のエントリーは、 name とdatabase を指定し、サブスクライブするパブリケーションを定義する必要があります。サブスクリプションの他のオプションの属性を指定する場合があります。

subscriptions:

- type: pglogical
  database: example
  name: some_subscription_name
  node_name: optional_pglogical_node_name
  publication:
    name: some_publication_name
  # Optional attributes:
  synchronize_structure: true
  synchronize_data: true
  forward_origins: [all]
  strip_origins: false
  apply_delay: 1 second
  writer: heap
  writer_options:
    - magic
    - key=value
    - just-a-string
  # Optional attributes that can be changed for an existing
  # subscription:
  replication_sets:
    - default
    - default_insert_only
    - custom_replication_set
  enabled: true

サブスクリプションは、(上記のように) publication.name を設定して、サブスクライブするパブリケーションを定義できます。その名前のパブリケーションが (クラスター全体に) ある場合は、明確にするインスタンスの名前を指定できます。パブリケーションを名前で参照する場合は、同じインスタンスに同じ名前で複数のパブリケーションを作成しないでください。

- type: pglogical
  …
  publication:
    name: some_publication_name
    instance: kazoo

  # OR

  provider_dsn: "host=… dbname=…"

出版物を名前で参照する代わりに、 provider_dsn を明示的に指定できます。この場合、指定されたDSNはpglogical.create_subscription() に直接渡されます(そして publication は無視されます)。このメカニズムを使用して、TPAクラスターの外部のインスタンスにサブスクライブできます。

上記の例の他の属性はオプションです。定義されている場合、それらは pglogical.create_subscription() への呼び出しに名前付けパラメーターとして含まれます。それ以外の場合、それらは除外されます。 (表示されている属性の一部はpglogical3に固有です。)

構成の変更

パブリケーションの場合、レプリケーションセットを追加または削除したり、レプリケーションセットの属性を変更したり、そのメンバーシップ (それに含まれるテーブルとシーケンス) を変更したりできます。

replicate_* またはautoadd_* を変更すると、TPAはそれに応じてpglogical.alter_replication_set() を呼び出します(ただし、既存のレプリケーションセットのautoadd_existing は変更できず、 autoadd_* パラメーターはすべてpglogical3固有です)。

複製セットのtables またはsequences のリストを変更すると、TPAは必要に応じてpglogical.alter_replication_set_{add,remove}_{table,sequence}() を呼び出してこれらの変更を調整します。

ただし、既にレプリケーションセットのメンバーであるリレーション(テーブルまたはシーケンス)の synchronize_data または他の属性を変更した場合、TPAは変更を伝播しません(たとえば、テーブルを削除して別の構成で再度追加します) 。

サブスクリプションの場合、replication_sets のリストを変更し、サブスクリプション(enabled: false )を有効または無効にすることのみできます。

どちらの場合も、存在するが構成に記載されていない複製セットは削除されます(サブスクライバーのpglogical.alter_subscription_remove_replication_set() 、またはパブリッシャーのpglogical.drop_replication_set() を使用します。ただし、default 、default_insert_only 、およびddl_sql という名前のデフォルトの複製セットは削除されません。)

config.ymlを編集する場合は、 tpaexec deploy を実行する前にtpaexec provision を実行することを忘れないでください。

BDRとの相互作用

注意を払えば、 BDRとpglogicalを同じデータベースで一緒に使用することができます。

BDR3は内部でpglogical3を使用し、存在しない場合はpglogicalノードを作成します。データベースごとに1つのpglogicalノードしか存在できないため、bdr_database でpglogicalパブリケーションを構成する場合、インスタンスのbdr_node_name はパブリケーションのname と同じである必要があります。そうしないと、最初にパブリケーション用にノードが作成され、後で bdr.create_node() がノード名の競合に関するエラーで失敗します。 bdr_database のsubscriptions も同じnode_name を使用する必要があります。

BDRの以前のバージョンはpglogicalを使用しないため、これらの考慮事項は適用されません。

制限

  • 現在、pglogical.replication_set_{add,remove}_ddl() のサポートはありません

  • 現在、pglogical.replication_set_add_all_{tables,sequences}() のサポートはありません

  • 現在、pglogical.alter_subscription_{interface,writer_options}() またはpglogical.alter_subscription_{add,remove}_log() はサポートされていません

  • pglogical v1のサポートは現在テストされていません。