EDB Postgres Distributed configuration

EDB Postgres Distributed configuration#

TPAは、 EDB Postgres DistributedPGD、以前はBDR双方向レプリケーションバージョン3.7、4.x、5.xとして知られていたものをインストールおよび構成できます。と6.x

PGDパッケージへのアクセスは、EDBのパッケージリポジトリを介してのみです。パッケージをダウンロードするには、有効なEDBサブスクリプショントークンが必要です。

このドキュメントでは、 PGD構成のいくつかの側面について触れていますが、詳細の信頼できる説明については PGDdocumentation を参照してください。

はじめに#

TPAは、 Postgres自分自身とともにPGDと依存関係をすべてのPGDインスタンスにインストールします。

基本的なPostgresのセットアップを完了し、Postgresを起動した後、TPAはbdr_database を作成し、以下で説明するさまざまな手順を介してPGDクラスターのセットアップを続行します。

インストール#

TPAは、使用中のPostgresのバージョンとフレーバーPostgres、Postgres Extended、またはEPASなどに応じて、正しいPGDパッケージをインストールします。

bdr_version を設定して、PGDのどのメジャーバージョン3、4、5、6をインストールするかを決定します。 bdr_package_version を設定して、インストールする正確なパッケージを決定しますたとえば、最新の5.0.xをインストールする場合は ‘5.0*’ 。

クラスターセットアップの概要#

必要なパッケージをインストールし、PGDをロードするようにPostgresを構成し、サーバーを起動した後、TPAはPGDノード、グループ、レプリケーションセット、およびその他のリソースのセットアップを続行します。

次に、TPAが実行する手順の概要を示します。

  • 参加するインスタンスごとにPGDノードを作成します bdr.create_node()

  • bdr_node_groups に応じて、1つ以上のPGDノードグループを作成しますbdr.create_node_group()を使用

  • 必要に応じて、レプリケーションセットを作成して、どの変更をレプリケートするかを正確に制御しますノードグループタイプとメンバーシップによって異なります。たとえば、サブスクライバ専用ノードと監視ノードは特別な処理が必要な場合があります。

  • 個々のインスタンスで関連するノードグループに参加する

  • サブグループRAFTまたはプロキシルーティングを有効にするなど、追加構成を実行します。

このプロセスには、クエリの複雑なシーケンスの実行が含まれます。一部は各インスタンスで順番に、他はパラレルで。手順を簡単に行うために、TPAは任意のPGDプライマリインスタンスをクラスターの「first_bdr_primary」として指定し、これを使用しますインスタンスを使用して、これらのクエリのほとんどを実行します。インスタンスはそれ以外の点では特別ではなく、そのIDはPGD構成自分自身にとって重要ではありません。

インスタンスロール#

role にbdr を含むすべてのインスタンスはPGDインスタンスであり、暗黙的にpostgres サーバーインスタンスでもあります。

ロールにreadonly が含まれるPGDインスタンスは、ロジカルスタンバイノード pause_in_standby 設定でPGDノードグループに参加します。昇格の対象です。

ロールにsubscriber-only を持つPGDインスタンスはサブスクライバー専用ノードであり、レプリケートされた変更を受信しますが、公開しません。

ロールにwitness が含まれるPGDインスタンスは、監視ノードです。

上記のすべてのPGDインスタンスは、暗黙的にprimary インスタンスでもあります。例外は、ロールにreplica を持つインスタンスです。これは、上流のPGDインスタンスの物理的ストリーミングレプリカを示します。このようなインスタンスは、推奨されるPGDアーキテクチャには含まれておらず、現在TPAではサポートされていません。

構成設定#

以下で説明する設定は、クラスター内のすべてのPGDインスタンスに均一に設定されるように、通常はcluster_vars で設定する必要があります。一部の場合bdr_database など、さまざまなインスタンスに異なる値を設定できますが、他の場合、結果は未定義ですたとえば、すべてのインスタンスが完全に同じ値のbdr_node_groups を持つ必要があります。

cluster_vars の下でクラスター全体の均一な値を設定することにより、PGD構成を定義することを強くお勧めします。

bdr_database#

bdr_database デフォルトbdrdbはPGDで初期化されます。

bdr_client_dsn_attributes#

bdr_client_dsn_attributes には、 追加 の parameter keywords supported by libpq を含めることができます。

host 、port 、dbname 、およびuser は含めないでください。これらは既に接続文字列に含まれています。

これらのドライバーは、libpq Cライブラリが提供するDSN属性の完全なセットをサポートしていません。

pgd-proxyおよび/またはpgd-cliがインストールされ、 bdr_client_dsn_attributes にGoドライバーで サポートされていない パラメータータイムアウトなどが含まれている場合、2つの新しい変数をクラスター構成に含める必要があります。

  • pgd_proxy_dsn_attributes pgd-proxy-conf で接続文字列を作成するために使用されます

  • pgd_cli_dsn_attributes pgd-cli-conf で接続文字列を作成するために使用されます

これらの2つの文字列には、Goドライバーと互換性のあるパラメーターキーワードのみが含まれている必要があります。

bdr_client_dsn_attributes がサポートされていないパラメーターを含まない場合、これは無視でき、 bdr_client_dsn_attributes はpgd-proxy-conf およびpgd-cli-conf の接続文字列に含まれます。

bdr_node_group の設定デフォルトクラスター名に基づいて、インスタンスがどのPGDクラスターに参加するかを指定します。外部コンポーネントたとえば、pgd-proxyまたはharp-proxyなどの特定のクラスターを識別するためにも使用されます。

bdr_node_groups#

これは、グループ参加ステージ前に作成する必要があるPGDノードグループのリストですクラスターに追加のサブグループが必要な場合。

通常、tpaexec configure は、選択したアーキテクチャに基づいて適切な値を生成します。

cluster_vars:
  bdr_node_groups:
  - name: topgroup
  - name: abc_subgroup
    node_group_type: data
    parent_group_name: topgroup
    options:
      location: abc
  …

最初のエントリーは、クラスターのbdr_node_group 用である必要があります。

リストの後続の各エントリはparent_group_name を指定する必要があり、 node_group_type オプショナルを指定する場合があります。

各エントリは、グループオプションのオプションのキー/値のマッピングを持つ場合があります。使用可能なオプションはPGDバージョンによって異なります。

bdr_child_group#

インスタンスにbdr_node_groups で記載されているグループの名前にbdr_child_group が設定されている場合、bdr_node_group の代わりにそのグループに参加します。

bdr_commit_scopes#

これは commit scopes のオプショナルリストです

PGDデータベースPGD 4.1以降で利用可能に存在する必要があります。

cluster_vars:
  bdr_commit_scopes:
  - name: somescope
    origin: somegroup
    rule: ALL (somegroup) ON received …`
  - name: otherscope
    origin: othergroup
    rule: …
  …

各エントリは、コミットスコープのname 、origin グループの名前、およびコミットスコープrule を指定する必要があります。グループはbdr_node_groups のエントリに対応する必要があります。

bdr_commit_scopes を明示的に設定すると、TPAは必要に応じてコミットスコープを作成、変更、またはドロップして、データベースが構成と一致することを確認します。設定しない場合、既存のコミットスコープはそのままになります。

preferred_first_bdr_primary#

これは、TPAが単一のノードでのみ実行されるPGD関連のタスクに使用するインスタンスの名前です。これには、 DDL/DMLの実行が含まれ、レプリケーションによって他のPGDノードに伝播されます。また、新しいPGDノードを初期化するためのデータの読み取りも含まれます。設定されていない場合、または使用できないインスタンスに設定されている場合、TPAは適切な候補が存在する場合にインスタンスを任意に選択します。

TPAによって選択されたインスタンスは、ファクトfirst_bdr_primary に保存されます。実行可能なインスタンスのリストは、ファクトfirst_bdr_primary_candidates に保存されます。これらのファクトはいずれもconfig.yml から設定できません。フックまたはデバッグで使用するためにここにノートされています。

注釈

preferred_first_bdr_primary の選択は、展開されたクラスター内の書き込みリーダーとして選択されるノードに影響を与えません。

単一のオペレーションにpreferred_first_bdr_primary を設定する場合は、 config.yml で指定するのではなく、Ansible -e オプションを使用してそれを渡すことができます。例

tpaexec deploy . -e preferred_first_bdr_primary=instance_name

これは、PGDノードを追加または再構築しており、たとえば同じデータセンター内のノードからデータを確実にクローンしたい場合に役立ちます。

同様に、各ノードに異なるインスタンスを使用して、 preferred_first_bdr_primary をインスタンス変数として設定できます。たとえば、この構成は、 node1 がリビルドされる場合、 tpaexec deploy コマンドは、リビルドのデータソースとしてnode2 を優先することを意味します。

instances:
  - Name: node1
    ...
    instance_vars:
      preferred_first_bdr_primary: node2

この構成を使用する場合、ノードが最初に展開された後に適用する必要があります。最初の展開時にpreferred_first_bdr_primary の複数の値を設定することはお勧めできません。

その他のノート#

フック#

TPAは、 PGDクラスターセットアッププロセス中にbdr-node-pre-creation、bdr-post-group-creation、およびbdr-pre-group-join TPA hooks を呼び出します。

データベースの照合順序#

TPAは、クラスター内のすべてのインスタンスのPGDデータベースが同じ照合順序LC_COLLATE設定があることを確認します。同じPGDクラスター内のデータベースに異なる照合順序があると、データ損失のリスクが発生します。

PGDの古いバージョン#

TPAは、 BDR v1 Postgres 9.4のパッチ適用バージョンを使用、v2 Postgres 9.6、またはv3.7より前のPGDバージョンの展開を積極的にサポートまたはテストしなくなりました。

目次