現在、pglogical のレプリケーションと管理にはスーパーユーザー権限が必要です。後で、より詳細な権限に拡張される可能性があります。
UNLOGGED と TEMPORARY は複製されません¶UNLOGGED および TEMPORARY
テーブルは、物理ストリーミングレプリケーションと同様に、レプリケートされません。
複数のデータベースをレプリケートするには、それぞれに対して個別のプロバイダー/サブスクライバーの関係を設定する必要があります。 PostgreSQL インストール内のすべてのデータベースのレプリケーションを一度に構成する方法はありません。
UPDATE s および DELETE s は、PRIMARY KEY
またはインデックスを使用するなどの他の有効なレプリカ ID
がないテーブルに対して複製することはできません。インデックスは一意であり、部分的ではなく、遅延可能ではなく、NOT
NULL
とマークされた列のみを含む必要があります。一意の識別子がないため、レプリケーションは更新/削除する必要があるタプルを見つける方法がありません。
REPLICA IDENTITY FULL はまだサポートされていません。
複数のアップストリームが構成されているか、ダウンストリームがローカル書き込みを受け入れる場合、ダウンストリームの複製されたテーブルには
UNIQUE インデックスが 1
つだけ存在する必要があります。競合解決では一度に 1
つのインデックスしか使用できないため、行が PRIMARY KEY
を満たしているが下流側で UNIQUE 制約に違反している場合、競合する行は
ERROR になる可能性があります。これにより、ダウンストリーム
テーブルが変更されて違反が解消されるまで、レプリケーションが停止します。
ダウンストリームがそのアップストリームからのみ書き込みを取得し、他のどこにも書き込みを取得しない場合は、アップストリームに追加の一意の制約を設定しても問題ありません。ルールは、下流の制約が上流の制約よりも制限的であってはならないということです。
部分的なセカンダリ ユニーク インデックスは許可されますが、競合解決のために無視されます。
下流側では、pglogical は DEFERRABLE として定義されたインデックス
ベースの制約をサポートしていません。エラーが発生します
ERROR: pglogical doesnt support index rechecks needed for deferrable indexes
DETAIL: relation "public"."test_relation" has deferrable indexes: "index1", "index2"
テーブルに変更を適用しようとしたときに、そのようなインデックスが存在する場合。
自動DDLレプリケーションはサポートされていません。プロバイダー データベースとサブスクライバー データベースの互換性を維持するためのDDLの管理は、ユーザーの責任です。
pglogical は pglogical.replicate_ddl_command
関数を提供して、プロバイダーとサブスクライバーで一貫した時点でDDLを実行できるようにします。
マスターでトランザクションをフリーズし、保留中のキューに入れられたすべての xacts がスロットからリプレイされるまで待機することはサポートされていません。このためにアップストリームを読み取り専用にするためのサポートは、将来のリリースで追加される予定です。
つまり、テーブル構造の変更を適用するときは注意が必要です。まだレプリケートされていないコミットされたトランザクションがあり、プロバイダーとサブスクライバーのテーブル構造が同時に変更され、サブスクライバー テーブルがキューに入れられたトランザクションと互換性がなくなる場合、レプリケーションは停止します。
管理者は、スキーマの変更を行う前にマスターへの書き込みが停止されていることを確認するか、pglogical.replicate_ddl_command
関数を使用してスキーマの変更をキューに入れ、レプリカの一貫した時点で再生されるようにする必要があります。
マルチマスター レプリケーション
サポートが追加されると、パブリッシャーでスキーマ変更がコミットされた後、サブスクライバーが古い構造で新しい
xacts を生成する可能性があるため、pglogical.replicate_ddl_command
を使用するだけでは十分ではありません。ユーザーは、スキーマの変更を行う前に、すべてのノードで書き込みが停止され、すべてのスロットが追いつくようにする必要があります。
レプリケーション
プロセスには外部キー制約は適用されません。FOREIGN KEY
に違反したとしても、プロバイダー側で成功したものがサブスクライバーに適用されます。
TRUNCATE ... CASCADE を使用すると、プロバイダー側で CASCADE
オプションのみが適用されます。
(これを適切に処理するには、PostgreSQL の外部キーに対する
ON TRUNCATE CASCADE サポートを追加する必要があります)。
TRUNCATE ... RESTART IDENTITY はサポートされていません。 ID
再開ステップはレプリカに複製されません。
複製セットに追加されたシーケンスの状態は、リアルタイムではなく定期的に複製されます。サブスクライバーがシーケンスの将来の状態を実際に受信できるように、複製される値に動的バッファーが使用されます。これにより、シーケンスの
last_value
が遅れるというサブスクライバーの概念の可能性が最小限に抑えられますが、可能性が完全に排除されるわけではありません。
synchronize_sequence を呼び出して、データの読み込みやオンライン
アップグレードなどのデータベースでの「大きなイベント」の後、すべてのサブスクライバーが特定のシーケンスに関する最新の情報を確実に入手できるようにすることが望ましい場合があります。
通常、マルチノード システムのシーケンスには bigserial および
bigint
タイプを使用することをお勧めします。小さいシーケンスは、シーケンス
スペースの最後にすばやく到達する可能性があるためです。
プロバイダーとサブスクライバーに独立したシーケンスを持たせたいユーザーは、レプリケーション
セットにシーケンスを追加することを避け、ノード数以上のステップ間隔でシーケンスを作成できます。次に、各ノードに異なるオフセットを設定します。
CREATE SEQUENCE または ALTER SEQUENCE には INCREMENT BY
オプションを使用し、setval(...) を使用して開始点を設定します。
適用プロセスと初期 COPY プロセスの両方が session_replication_role を
replica に設定して実行されます。これは、ENABLE REPLICA および
ENABLE ALWAYS トリガーが起動されることを意味します。
PGLogical は、PostgreSQL のメジャー バージョン間で複製できます。それにもかかわらず、長期的なクロスバージョン レプリケーションは設計目標とは見なされていませんが、多くの場合は機能する可能性があります。変更がプロバイダーでは有効であるが、サブスクライバーでは有効でないという問題は、バージョン間でレプリケートするときに発生する可能性が高くなります。
PostgreSQL は完全な後方互換性を維持していますが、前方互換性は限られているため、古いバージョンから新しいバージョンに複製する方が安全です。初期スキーマ同期は、同じバージョンの PostgreSQL 間、または下位バージョンから上位バージョンに複製する場合にのみサポートされます。
異なるマイナー バージョン間で複製しても、まったく違いはありません。
PGLogical
は、エンコーディングが異なるデータベース間のレプリケーションをサポートしていません。レプリケートされたすべてのデータベースで
UTF-8 エンコーディングを使用することをお勧めします。
PostgreSQL の論理デコード機能は、大きなオブジェクトへの変更のデコードをサポートしていないため、pglogical は大きなオブジェクトを複製できません。
サポートされている Postgres-XL の最小バージョンは 9.5r1.5 です。
Postgres-XL は、サブスクライバーとしてのみサポートされます (プロバイダーになることはできません)。小さなトランザクションが多数含まれるワークロードでは、書き込みレイテンシが増加するため、レプリケーションのパフォーマンスが低下する可能性があります。一方、大規模な挿入 (または一括コピー) トランザクションは、Postgres-XL で非常に高速に動作するように大幅に最適化されています。
また、すべてのDDL制限が適用されるため、replicate_ddl_command()
を使用する場合は特別な注意が必要です。
Postgres-XL は、pglogical.conflict_resolution および
pglogical.use_spi
構成オプションのデフォルトと使用可能な設定を変更します。
