Limitations and restrictions
============================

スーパーユーザーが必要です
--------------------------

現在、pg論理レプリケーションと管理にはスーパーユーザー権限が必要です。これは、後でより詳細な特権に拡張される場合があります。

``UNLOGGED`` および\ ``TEMPORARY`` はレプリケートされません
-----------------------------------------------------------

``UNLOGGED`` および\ ``TEMPORARY`` テーブルは、
物理的ストリーミングレプリケーションの場合と同様に、レプリケートされず、レプリケートできません。

一度に1つのデータベース
-----------------------

複数のデータベースをレプリケートするには、それぞれに個々のプロバイダー/サブスクライバー関係を設定する必要があります。
PostgreSQLインストール内のすべてのデータベースのレプリケーションを一度に構成する方法はありません。

PRIMARY KEYまたはREPLICA IDENTITYが必要です
-------------------------------------------

``UPDATE`` sおよび\ ``DELETE`` sは、 ``PRIMARY KEY``
またはインデックスを使用するなどの他の有効なレプリカIDが欠如しているテーブルにはレプリケートできません。インデックスは一意で、部分的ではなく、遅延不可で、NOT
NULLとしてマークされた列のみを含む必要があります。一意の識別子がないため、レプリケーションは更新/削除するタプルを見つける方法がありません。
``REPLICA IDENTITY FULL`` はまだサポートされていません。

一意のインデックス/コンストレイン/PKは1つだけ
---------------------------------------------

複数のアップストリームが構成されている場合、またはダウンストリームがローカル書き込みを受け入れる場合、ダウンストリームのレプリケートテーブルには1つの\ ``UNIQUE``
インデックスのみが存在する必要があります。競合解決では一度に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レプリケーションはサポートされていません。プロバイダーとサブスクライバーデータベースの互換性を保つようにDDLを管理することはユーザーの責任です。

pglogicalは、 ``pglogical.replicate_ddl_command``
ファンクションを提供して、一貫したポイントでプロバイダーとサブスクライバーでDDLを実行できます。

レプリケーションキューのフラッシュなし
--------------------------------------

マスターでのトランザクションのフリーズと、保留中のキューに入れられているすべてのxactがスロットから再生されるまで待機することはサポートされていません。これのアップストリームを読み取り専用にするサポートは、将来のリリースで追加される予定です。

これは、テーブル構造の変更を適用するときに注意する必要があることを意味します。まだレプリケートされていないコミットされたトランザクションがあり、サブスクライバテーブルとキュー内のトランザクションとの互換性をなくす方法でプロバイダーとサブスクライバーのテーブル構造が同時に変更された場合、レプリケーションは停止します。

管理者は、スキーマを変更する前にマスターへの書き込みが停止していることを確認するか、
``pglogical.replicate_ddl_command``
ファンクションを使用してスキーマ変更をキューに入れて、レプリカの一貫したポイントで再生されるようにする必要があります。

マルチマスターレプリケーションのサポートが追加されると、パブリッシャーでスキーマ変更がコミットされた後、サブスクライバーが古い構造で新しいxactを生成する可能性があるため、\ ``pglogical.replicate_ddl_command``
を使用するだけでは十分ではありません。ユーザーは、スキーマを変更する前に、すべてのノードで書き込みが停止され、すべてのスロットがキャッチされていることを確認する必要があります。

外部キー
--------

外部キー制約はレプリケーションプロセスに適用されません。プロバイダー側で成功したものは、\ ``FOREIGN KEY``
に違反する場合でもサブスクライバーに適用されます。

TRUNCATE
--------

``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`` トリガーが起動されることを意味します。

PostgreSQLバージョンの違い
--------------------------

PGLogicalは、PostgreSQLメジャーバージョン間でレプリケートできます。それにもかかわらず、長期的なクロスバージョンのレプリケーションは、多くの場合機能する場合がありますが、デザインターゲットとは考えられません。プロバイダーでは変更が有効だが、サブスクライバーでは有効でない問題は、バージョン間でレプリケートするときに発生する可能性が高くなります。

PostgreSQLは強固な下位互換性を維持しますが、限定的な前方互換性のみを維持するため、古いバージョンから新しいバージョンに複製する方が安全です。初期スキーマの同期は、PostgreSQLの同じバージョン間または下位バージョンから上位バージョンに複製する場合にのみサポートされています。

異なるマイナーバージョン間でレプリケートしても、まったく違いはありません。

データベースエンコーディングの違い
----------------------------------

PGLogicalは、エンコードが異なるデータベース間のレプリケーションをサポートしていません。すべてのレプリケートデータベースで\ ``UTF-8``
エンコードを使用することをお勧めします。

ラージオブジェクト
------------------

PostgreSQLの論理デコード機能は、ラージオブジェクトのデコード変更をサポートしていないため、pglogicalはラージオブジェクトをレプリケートできません。

Postgres-XL
-----------

Postgres-XLの最小サポートバージョンは9.5r1.5です。

Postgres-XLは、サブスクライバーとしてのみサポートされていますプロバイダーになることはできません。多くの小規模なトランザクションを含むワークロードの場合、書き込みレイテンシーの増加により、レプリケーションのパフォーマンスが低下する場合があります。一方、大規模な挿入または大量コピートランザクションは、Postgres-XLで非常に高速に動作するように高度に最適化されています。

また、 DDL制限が適用されるため、 ``replicate_ddl_command()``
を使用するときは特に注意する必要があります。

Postgres-XLは、 ``pglogical.conflict_resolution``
および\ ``pglogical.use_spi``
構成オプションのデフォルトと使用可能な設定を変更します。
