Fine-tuning with custom scopes#

カスタムスコープを使用して、アプリケーションに正確な耐久性と、複雑なマルチグループ環境全体での一貫性の保証を提供します。各句は、独自の確認要件を独立して定義し、どのノードが応答する必要があるか、数、およびどのような確認が適用されるかをカバーします。句を結合することにより、単一のコミット内の異なるノードグループに異なる耐久性要件を適用できます。

カスタムスコープの構築#

すべてのカスタムスコープ定義は、3つの質問に答えます。

Formula showing commit scope equals which group plus who confirms plus how.#

各句は「誰が確認しますか?」を組み合わせています。「どうやって？」 AND を使用して必要な数の句を組み合わせ、同じコミット内のノードグループ全体に異なる耐久性要件を適用します。 PGDは各句を独立して評価し、コミットが返される前にすべてが満たされる必要があります。

Diagram showing origin group combined with two confirming nodes and commit mode pairs joined by AND.#

カスタムコミットスコープを作成するときに、以下を定義します。

commit_scope_name を介した一意の名前。スコープを参照およびノードグループまたは個々のトランザクションに割り当てるために使用されます
origin_node_group を介して、スコープがどのグループに適用されるか。このグループまたはそのサブグループのノードから発生したトランザクションは、スコープを使用します
誰がどのように確認するかを指定するrule 文字列
確認するノードは、確認する必要がある数とそれらがどのグループから来たかを定義する Commit scope groups として表されます。
確認のタイプはコミット種類の選択であり、それが耐久性、クォーラム契約、有界ラグ、またはシングルコミットの強制。
オプションで、 DEGRADE ON はタイムアウトを設定し、その後、必要なノードが時間内に応答しない場合、句は非同期にフォールバックします。

オプションで、 wait_for_ready を指定して、スコープがすべてのノードでアクティブになるまで、呼び出しをブロックしてから戻ります。

たとえば、コミットが返される前にローカルノードの大部分が同期的に確認を必要とするスコープを定義します。

Anatomy of a commit scope, showing commit_scope_name, origin_node_group, confirming nodes, commit mode, and degrade fallback color-coded in the function call.#

この例では、ルールはグループmy_group 内のノードの大部分を確認する必要がありますMAJORITY ORIGIN GROUP 、コミット種類SYNCHRONOUS COMMIT として同期コミットを使用します。

コミット種類の選択#

コミット種類を選択して、ワークロードにとって確認が何を意味するかを定義します。正しい選択は、どれくらいのレイテンシーを許容できるか、コミット時に競合を防ぐ必要があるかどうか、およびアプリケーションが再試行を処理する方法によって異なります。

** Synchronous Commit ** は、コミットが返される前に、指定されたピアからの承認が必要です。 DEGRADE ON と組み合わせて、必要なピアが応答しない場合、タイムアウト後に非同期にフォールバックします。
** How Quorum Commit works ** では、すべての参加ノードがノードをコミットする前にトランザクション結果に同意する必要があり、競合する変更がノード間で独立してコミットされることを防ぎます。
** Commit At Most Once ** Commit At Most Onceワンスは、ノード全体にシングルコミットセマンティクスを適用し、接続障害の後にクライアントが再試行するときにトランザクションが複数回適用されるのを防ぎます。アプリケーションに Commit At Most Once を実装して、再試行する前にトランザクションステータスを確認する必要があります。
** Lag Control ** は、最大遅延しきい値によってゲートされた非同期セマンティクスを提供します。クラスターがしきい値に近づくと、PGDはアプリケーショントラフィックを調整して、暴走遅延を防ぎます。コミットはローカル耐久性の後に返されますが、しきい値を突破する前に書き込みが遅くなります。

Commit kind	Best for	Key trade-off
Synchronous Commit	Geo-distributed workloads requiring confirmation that data is persisted on remote nodes before the commit returns, with optional graceful degradation when peers are slow to respond	Higher commit latency than async
Quorum Commit	High-value workloads in payments, banking, or telecom where conflicting commits can't be untangled after the fact	Higher per-transaction latency, and a majority must participate
CAMO	Workloads where processing a transaction twice causes real harm, such as payments or inventory updates, and where your application can implement a status check before retrying	Application must implement a verification step before retrying
Lag Control	High-throughput ingest pipelines that need async performance but can't tolerate unbounded replication lag	Commits throttle or block when lag threshold is reached

注釈

コミット種類は、競合の防止ではなく、耐久性を保証します。 2つのノードは引き続き独立してコミットできますが、競合する変更は事後的に表面化し、タイムスタンプまたはその他のコミット後戦略を使用して解決されます。 Conflict Management を参照してください。他のコミット種類と異なり、クォーラムコミットは、後で解決するのではなく、コミット時に競合を防止します。

コミットスコープの適用#

3つの粒度レベルでスコープを適用できます。トランザクションレベルの設定はセッションレベルの設定をオーバーライドし、結果的にグループのデフォルトをオーバーライドします。

グループごと アプリケーションコードを変更せずに、そのグループから発生するすべての書き込みの一貫したデフォルトが必要な場合、ノードグループにデフォルトスコープを設定します。

SELECT bdr.alter_node_group_option(
    node_group_name := my_group,
    config_key := default_commit_scope,
    config_value := my_scope
);

セッションごと すべてが同じスコープを必要とする操作のバッチを実行するとき、またはグループレベルのデフォルトにコミットする前にスコープをテストするときに、スコープを構成パラメーターとして設定します。スコープは、変更されるか、セッションが終了するまで、セッション内のすべてのトランザクションに適用されます。

SET bdr.commit_scope = my_scope;

トランザクションごと 他のすべてに影響を与えることなく、特定の高価値操作に別の耐久性保証が必要な場合、トランザクションブロック内にスコープを設定します。書き込みを発行する前にスコープを設定する必要があります。

BEGIN;
SET LOCAL bdr.commit_scope = my_scope;
-- application writes
COMMIT;

例ローカルマジョリティとクロスリージョンの確認の組み合わせ#

地域分散ワークロードが強力なローカル耐久性とクロスリージョンの確認を必要とするが、リモートリージョンが利用できない場合にブロックする余裕がない場合、ローカルマジョリティ句とクロスリージョン句および低下タイムアウトをペアにします。この例では、2つのアクティブデータグループリージョンAおよびリージョンB、それぞれに3つのデータノードを持つ Two data groups, active-active トポロジと、リージョンCの単一の監視ノードを使用します。

SELECT bdr.create_commit_scope(
    commit_scope_name := regional_ha,
    origin_node_group := region_a,
    rule := MAJORITY ORIGIN GROUP SYNCHRONOUS COMMIT
             AND ANY 1 NOT ORIGIN GROUP SYNCHRONOUS COMMIT
                 DEGRADE ON (timeout = 10s, require_write_lead = true) TO ASYNCHRONOUS COMMIT,
    wait_for_ready := true
);

このスコープは、 AND で結合された2つの句を使用します。赤いボックスはローカル句を示しており、A2書き込みリーダーとA3がMAJORITY ORIGIN GROUP を満たす。オレンジ色のボックスはクロスリージョン句を示しており、オリジンノードとしてのA2は両方に参加し、リージョンBのB2はANY 1 NOT ORIGIN GROUP を満たす。各句は独立して評価され、コミットが返される前に両方が満たされる必要があります。 DEGRADE ON は、crossregion句にのみ適用されます。 B2が10秒以内に確認できない場合、クロスリージョン句は非同期にフォールバックしますが、ローカルマジョリティ要件は適用されたままです。

Topology diagram showing two selection boxes. The red box covers A2 and A3 in Region A as the local majority. The orange box spans A2 and B2 across regions as the cross-region confirmation clause.#

ワークロードによっては、このスコープをセッションまたはトランザクションレベルで適用することもできます。たとえば、グループからのすべてのトラフィックではなく、特定の高価値の書き込みにのみ厳密な耐久性を適用できます。

例すべてのローカルノードと2つのクロスリージョンノードを必要とする#

部分的な確認が受け入れられない場合、完全なコンセンサスを必要とする規制業界または金融システムなど、すべてのローカルノードと2つのリモートノードがフォールバックなしで確認する必要があります。同じ Two data groups, active-active トポロジに基づいて構築され、 ALL ORIGIN GROUP はマジョリティではなくリージョンAのすべてのノードの確認を必要とし、 ANY 2 NOT ORIGIN GROUP は1つではなく2つのリージョンBノードの確認が必要です。

SELECT bdr.create_commit_scope(
    commit_scope_name := strict_ha,
    origin_node_group := region_a,
    rule := ALL ORIGIN GROUP SYNCHRONOUS COMMIT
             AND ANY 2 NOT ORIGIN GROUP SYNCHRONOUS COMMIT,
    wait_for_ready := true
);

ALL ORIGIN GROUP は、前の例では役割を果たさないA1を含むオリジングループ内のすべてのノードを選択するため、赤いボックスはA1、A2、およびA3をカバーしています。オレンジ色の選択はA2、B2、およびB3をカバーし、2つの矢印は両方のBノードが確認する必要があることを示しています。 DEGRADE ON 句がないため、必要なノードが確認できない場合、トランザクションは待機します。

Topology diagram showing two selection boxes. The red box covers all three Region A nodes as the local ALL clause. The orange selection spans A2, B2, and B3, with two solid arrows showing the two required cross-region confirmations.#

例支払いワークロードでの複数の耐久性要件の処理#

電信送金、POSトランザクション、およびバッチ決済ジョブを同じクラスターで処理する決済アプリケーションを検討します。異なるトランザクションタイプは異なるリスクを伴い、すべてに同じコミット種類を適用すると、重要度の低いパスが過剰保護されるか、高価値のパスが過小保護されます。

このシナリオでは、アプリケーションは2つの異なる耐久性の問題に直面しています。

競合するコミット 2つのノードが、それぞれ、他方を知ることなく同じアカウントに対する電信送金を承認でき、当座貸越が発生します。
重複コミット クライアントがコミット中に接続を失うと、トランザクションが成功したかどうかを判断できないため、再試行は支払いを2回処理するリスクを伴います。

これら2つの問題に対処するには、さまざまなコミットスコープの種類を使用します。

電信送金には How Quorum Commit works を使用します。ノードがトランザクションを終了する前に、ノードの大部分が同意する必要があります。同意できない場合、トランザクションはどこでもロールバックします。
ペイメントゲートウェイトランザクションには Commit At Most Once を使用します。これにより、アプリケーションは、再試行するかどうかを決定する前に、パートナーノードを照会して最終的な結果を照会できます。

同じクラスターで両方を適用するには、各コミット種類のスコープを定義し、グループのデフォルトとしてQuorum Commitを設定し、支払いゲートウェイパスのトランザクションごとにCAMOにオーバーライドします。

2つのスコープを定義します。

-- Quorum Commit scope for wire transfers
SELECT bdr.create_commit_scope(
    commit_scope_name := quorum_commit,
    origin_node_group := payments_group,
    rule := MAJORITY ORIGIN GROUP QUORUM COMMIT,
    wait_for_ready := true
);

-- CAMO scope for the payment gateway
SELECT bdr.create_commit_scope(
    commit_scope_name := payment_gateway_camo_scope,
    origin_node_group := payment_gateway_camo,
    rule := ALL (payment_gateway_camo) CAMO DEGRADE ON (timeout=500ms) TO ASYNC,
    wait_for_ready := true
);

クォーラムコミットを支払いグループのデフォルトとして設定します。

SELECT bdr.alter_node_group_option(
    node_group_name := payments_group,
    config_key := default_commit_scope,
    config_value := quorum_commit
);

厳密に1回のセマンティクスを必要とする決済ゲートウェイ操作のトランザクションごとにCAMOを適用します。

BEGIN;
SET LOCAL bdr.commit_scope = payment_gateway_camo_scope;
-- payment gateway writes
COMMIT;

Fine-tuning with custom scopes

目次