Nodes with differences

差分を含むノード間のレプリケーション

デフォルトでは、 DDLはすべてのノードに送信されます。

DDL replication filtering で説明しているように、この動作を制御でき、それを使用して、ノード間のデータベーススキーマ間の差異を作成できます。

PGDは、ノード間のわずかな違いがあってもレプリケーションを続行できるように設計されています。これらの機能は、ダウンタイムなしでアプリケーションスキーマを移行できるように、またはロジカルスタンバイノードでレポートまたはテストをできるように設計されています。

現在、レプリケーションには、すべてのノードで同じテーブル名が必要です。将来の機能では、異なるテーブル名間のマッピングが可能になる可能性があります。

ターゲット上のパーティションを変更する更新のサポートを含む、パーティションテーブルにレプリケートする通常のテーブルのソースなど、異なるパーティション定義を持つテーブル間でレプリケートが可能です。パーティショニング定義がソースとターゲットで同じである場合、適用時に動的パーティションルーティングを実行する必要がないため、高速になります。詳細については、

Replication sets を参照してください。

デフォルトでは、すべての列がレプリケートされます。

PGDは、列名に基づいてデータ列をレプリケートします。列の名前が同じで異なるデータ型がある場合、 PGDはソースタイプからターゲットタイプにキャストを試行します（それを許可するキャストが定義されている場合）。

PGDは、列数が異なるテーブル間のレプリケーションをサポートしています。

ターゲットにソースからの欠落列がある場合、 PGDはtarget_column_missing 競合を発生させます。デフォルトの競合リゾルバーはignore_if_null です。これは、NULL以外の値が到着した場合にエラーをスローします。または、ignore の競合リゾルバーを使用してノードを構成することもできます。この設定はエラーをスローしませんが、追加の列をサイレントに無視します。

ターゲットにソースレコードで見られない追加の列がある場合、 PGDはsource_column_missing 競合を発生させます。デフォルトの競合リゾルバーはuse_default_value です。追加列にデフォルトNULLヌル可能な場合またはデフォルト式がある場合、レプリケーションは続行されます。そうでない場合、エラーをスローし、レプリケーションを停止します。

変換トリガーはテーブルで使用して、デフォルト値を提供したり、適用前にさまざまな方法で受信データを変更したりすることもできます。

ソースとターゲットに異なる制約がある場合、レプリケーションが試行されますが、ソースからの行をターゲットに適用できない場合、失敗する場合があります。ここで行フィルタが役立ちます。

1つのスキーマからより緩和されたスキーマにデータを複製しても、障害は発生しません。スキーマからより制限的なスキーマへのデータの複製は、潜在的な障害のソースになる可能性があります。これを解決する正しい方法は、より緩和な側にコンストレインを配置して、悪いデータを入力できないようにすることです。このようにして、レプリケーションによって不正なデータが到着することはなく、より制限的なスキーマへの変換に失敗することはありません。たとえば、あるスキーマにTEXTタイプの列があり、別のスキーマがXMLと同じ列を定義している場合、 TEXT列にCHECK制約を追加して、テキストがXMLであることを強制します。

ノードごとに異なるインデックスを使用してテーブルを定義できます。デフォルトでは、インデックス定義はレプリケートされます。ノードのサブセットのみまたはローカルにインデックスを作成する方法を指定するには、

DDL replication filtering を参照してください。

fillfactor やtoast_tuple_target などのストレージパラメーターは、テーブルのノード間で問題なく異なる場合があります。その動作の例外は、テーブルのストレージパラメーターuser_catalog_table の値がすべてのノードで同一である必要があることです。

レプリケートされるテーブルは、各ノードで同じユーザー/ロールが所有している必要があります。詳細は、

Security and roles を参照してください。

ロールは、各ノードの接続に対して異なるパスワードを持つことができますが、デフォルトでは、ロールの変更は各ノードにレプリケートされます。ノードのサブセットのみまたはローカルでロールパスワードを変更する方法を指定するには、

DDL replication filtering を参照してください。

違いがあるノード間の比較

LiveCompareは、PGDノードおよび非PGDノードとデータベースのデータを比較するためのツールです。比較して最終結果に到達するには、少なくとも2つの接続が必要です。

LiveCompare 1.3以降、all_bdr_nodes セットを使用して構成できます。この設定により、クラスター内の個別のノードごとに関連するすべてのDSNを明確にする必要がありません。 EDB Postgres分散クラスターには、接続情報を備えたN個のノードがありますが、LiveCompare 1.3以降がジョブを完了するために必要な初期接続と出力接続のみです。 logical_replication_mode 設定は、すべてのノードがどのように通信しているかを示します。

すべての構成は、たとえば、 bdrLC.ini という名前の.ini ファイルで実行されます。 /etc/2ndq-livecompare/ でこの構成ファイルのテンプレートを見つけます。

LiveCompareの実行中、N+1の進行状況バーが表示されます。Nはプロセス数です。すべてのテーブルがソースされると、1秒あたりのトランザクションtpsが測定されたとして時間が表示されます。このメカニズムは時間をカウントし続け、推定を提供して、最後に合計実行時間を提供します。

このツールは、テーブル、スキーマ、replication_setsなど、多くのカスタマイズとフィルターを提供します。 LiveCompareは、コンテキスト情報を失うことなくstop-startを使用できるため、都合の良いときに実行できます。比較の後、概要とDMLスクリプトが生成されるので、確認できます。 DMLを適用して、見つかった差異を修正します。

異なるリリースレベル間のレプリケーション

ノード間のその他の違いは、ノードにPostgreSQLの異なるメジャーバージョンが存在するかどうかです。 PGDは、異なるメジャーリリースバージョン間で複製するように設計されています。この機能は、ダウンタイムなしでメジャーバージョンのアップグレードを可能にするように設計されています。

PGDは、PGDソフトウェアの異なるバージョンを持つノード間で複製するように設計されています。この機能は、ダウンタイムなしでバージョンのアップグレードとメンテナンスを可能にするように設計されています。

ただし、クラスター内のメジャーバージョンのノードを参加することは可能ですが、クラスターが新しいプロトコルバージョンを使用している場合、マイナーバージョンのノードを追加することはできません。そうするとエラーが返されます。

これらの機能は両方とも、特定の制限の影響を受ける可能性があります。既知の非互換性については、

EDB Postgres Distributed Release notes を参照してください。