Parallel Apply ============== パラレル適用とは何ですか? ------------------------- Parallel applyは、 PGDノードがサブスクリプションごとにマルチプルのライターを使用できるようにするPGDの機能です。この動作は、一般にサブスクリプションのスループットを向上させ、レプリケーションパフォーマンスを向上させます。 パラレル適用の構成 ^^^^^^^^^^^^^^^^^^ 2つの変数はPGD 5のパラレル適用を制御します :ref:`bdr.max_writers_per_subscription ` デフォルト8および :ref:`bdr.writers_per_subscription ` デフォルト2。 .. code:: plain bdr.max_writers_per_subscription = 8 bdr.writers_per_subscription = 2 この構成では、各サブスクリプションに2つのライターを与えます。ただし、状況によっては、システムはサブスクリプションに最大8つのライターを割り当てる場合があります。 :ref:`bdr.max_writers_per_subscription ` のみが変更できます サーバーを再起動します。 :ref:`bdr.writers_per_subscription ` を変更できます 再起動なしの特定のサブスクリプションの場合 1. :ref:`bdr.alter_subscription_disable ` を使用してサブスクリプションを停止します。 2. 新しい値の設定。 3. :ref:`bdr.alter_subscription_enable ` を使用してサブスクリプションを再開します。 ただし、最初に、 ``select * from bdr.subscription`` を使用してサブスクリプションの名前を確立します。この例では、サブスクリプション名は\ ``bdr_bdrdb_bdrgroup_node2_node1`` です。 .. code:: sql SELECT bdr.alter_subscription_disable (bdr_bdrdb_bdrgroup_node2_node1); UPDATE bdr.subscription SET num_writers = 4 WHERE sub_name = bdr_bdrdb_bdrgroup_node2_node1; SELECT bdr.alter_subscription_enable (bdr_bdrdb_bdrgroup_node2_node1); Parallel applyを使用する場合 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Parallel applyはデフォルトで常にオンになっており、ほとんどの操作では、オンのままにすることをお勧めします。 モニタリング パラレル 適用 ^^^^^^^^^^^^^^^^^^^^^^^^^^ Parallel applyのデッドロックの緩和をサポートするために、PGD 5.2は :ref:`bdr.stat_subscription ` に列を追加します。新しい列は\ ``nprovisional_waits`` 、\ ``ntuple_waits`` 、および\ ``ncommmit_waits`` です。これらは、Parallel applyが、以前はデッドロックであったものをどの程度適切に管理しているかを示すメトリックです。これらはシステム全体のパフォーマンスを反映するものではありません。 ``nprovisional_waits`` 値は、同時適用トランザクションによって実行されている同じタプルの操作の数を反映しています。これらは暫定的な待機で、実際にはまだ待機していませんが、待機する可能性があります。 タプルの書き込みが安全に適用できるまで待機する必要がある場合、\ ``ntuple_waits`` でカウントされます。コミットされる前に待機した完全に適用されたトランザクションは、 ``ncommit_waits`` でカウントされます。 パラレル適用の無効化 ^^^^^^^^^^^^^^^^^^^^ Parallel applyを無効にするには、 :ref:`bdr.writers_per_subscription ` を\ ``1`` に設定します。 デッドロックの軽減 ^^^^^^^^^^^^^^^^^^ Parallel applyが動作している場合、サブスクリプションからのトランザクションの変更は、マルチプルのライターによって書き込まれます。ただし、各ライタは、トランザクションの最終コミットが、オリジンノードで実行されたコミット順序に違反していないことを保証します。違反がある場合は、エラーが生成され、トランザクションをロールバックできます。 このメカニズムは、以前は、次のことがすべてtrueの場合、結果のエラーがデッドロックとして現れる可能性があることを意味しました。 - トランザクションはコミット保留中で、別のトランザクションが変更する必要がある行を変更します。 - 保留中のトランザクションが実行する前に、オリジンノードで他のトランザクションが実行されました。 - 保留中のトランザクションはロック要求を取り出しました。 さらに、エラーを処理すると、にかかった時間の組み合わせにより、レプリケーションラグが増加する可能性があります。 - デッドロックを検出するには - クライアントがトランザクションをロールバックする場合 - すでに適用された変更の間接的なガベージコレクションの場合 - 作業をやり直すには ここで、 PGD 5.2で導入されたParallel applyのデッドロック緩和が役立ちます。いかなるトランザクションでも、Parallel applyは、現在のトランザクションが書き込む行タプルに既にスケジュールされているトランザクションを調べます。見つかった場合、行は、行に変更を適用する前に、他のトランザクションがコミットされるまで待機する必要があるとしてマークされます。このアプローチにより、行が正しい順序で書き込まれます。 .. raw:: html パラレル適用のサポート ^^^^^^^^^^^^^^^^^^^^^^ PGD 5.1までは、 Group Commit、 CAMO、およびEager Replicationで Parallel apply を使用しないでください。これらのシナリオでは、パラレル適用を無効にします。 PGD 5.1以前を使用しているときに、大量のデッドロックが発生している場合は、パラレル適用を無効にするか、アップグレードを検討することもできます。 PGD 5.2から、 Parallel applyはCAMOで動作します。 Group CommitまたはEager Replicationを使用している場合は無効にします。