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