Configuring commit scopes for geo-replication#

コミットスコープは、 PGDがトランザクションを確認する方法と、コミットされたとみなされる前に書き込みを確認する必要があるノードの数を制御します。 geoレプリケーションでは、選択は書き込みレイテンシーと、ロケーションに障害が発生した場合にどの程度のデータが失われるリスクに直接影響します。

geoレプリケーションをサポートする展開パターンは、次のコミットスコープを使用します。

Commit scope	Description	Latency	Data loss risk	When to use	Supported topology patterns	Notes
Majority protect	コミットする前に、オリジングループ内のノードの大部分が確認するのを待機します。	Medium	Low	Zero data loss required and write latency is acceptable.<br /> Recommended for most production workloads.	Any group with 3+ nodes	Survives minority node failures.
Local protect	他のノードを待たずにローカルにコミットします。 <br />変更は非同期的に複製されます。	Lowest	Highest	Lowest possible write latency and some data loss on failure is acceptable.	Any topology	Not recommended for production use. <br /> Data loss possible if a node fails before replication.
Adaptive protect	利用可能な場合はマジョリティに同期し、タイムアウトデフォルト10秒後に非同期に低下します。	Variable	Low	Durability by default, but cluster must stay writable during partial failures.	Groups with 2 data nodes + witness	Balances durability and availability. <br /> Graceful degradation during node failures.
CAMO	専用のパートナーノードを使用した1回だけのセマンティクスによる同期レプリケーション。	Higher	None	Exactly-once transaction requirements where duplicate detection isn't possible at the application level.	Groups with exactly 2 data nodes	Prevents duplicate transactions after failover. <br /> Higher latency. Requires application changes.
Quorum Commit	ノードがローカルにコミットする前に、2フェーズコミットを使用して、すべての参加ノードにわたってコミット決定を調整します。競合するトランザクションは、コミットフェーズ中に検出され、中止されます。	High	None	Workloads requiring distributed transaction consistency where conflicts can't be resolved after the fact, such as payments, core banking, and ledger systems.	Any group with 3+ nodes (majority required)	No DEGRADE TO support. Requires write leader routing. Application must handle serialization errors and retry.

コミットスコープの選択#

コミットスコープの選択は、レイテンシー、耐久性、障害中の動作に直接影響を与える重要な決定です。

次の質問を使用して、展開に適切なコミットスコープを特定します。答えは、トポロジ、目標復旧ポイントRPO要件、およびワークロードに混合の耐久性のニーズがあるかどうかによって異なります。

ワークロードは、支払いやコアバンキングなど、競合するトランザクションが両方ともコミットできない厳密な分散一貫性を必要としますか?
Yes - Quorum Commit
No - continue
ロケーションに障害が発生した場合、アプリケーションはデータ損失を許容できますか
Yes —リモート確認なしのマジョリティ保護で十分です
No —リモートノード確認をルールに追加
グループごとに2つのデータノード+監視がありますか?
Yes —アダプティブ保護を使用しますb_tran_3 No —マジョリティ保護を使用
クロスロケーションの書き込みレイテンシーはすべてのトランザクションで許容されますか?
Yes —ルールにリモート確認を追加します
No —遅延制御でローカル耐久性を使用
異なる耐久性ニーズを持つワークロードが混合していますか
Yes — セッションまたはトランザクションをオーバーライドして複数のスコープを使用します
No — 単一のデフォルトスコープを使用します

1回だけのトランザクションセマンティクスを必要とするワークロードの場合、 CAMOは追加の保証を提供しますが、実装にはアプリケーションレベルの変更が必要です。詳細は、 Commit At Most Once を参照してください。

コミットスコープの作成#

コミットスコープを選択したら、ルールが適用されるオリジンノードグループごとにbdr.create_commit_scope() を使用します。ほとんどの地域分散展開では、 ORIGIN_GROUP が推奨されるアプローチです。トランザクションを開始したノードのサブグループに動的に解決されるため、クラスター全体に1つのルールのみが必要です。例、マジョリティ保護スコープを作成するには

SELECT bdr.create_commit_scope(
    commit_scope_name := majority_protect,
    origin_node_group := <top_group>,
    rule := MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT,
    wait_for_ready := true
);

ロケーションに非対称の耐久性要件がある場合は、代わりにロケーションごとに別個のルールを作成できます。詳細については、 Using Quorum Commit を参照してください。

マルチグループ展開でマジョリティ保護を使用する場合、クロスロケーションオプションでbdr.create_commit_scope() のrule パラメーターを拡張して、リモートノードがコミットに参加する方法を制御できます。

ローカル持続性のみ - オリジングループ内のノードの大部分が確認するとすぐにコミットします。変更はリモートの場所に非同期に複製されます。

MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT

リモート確認 — コミットする前に確認する少なくとも1つのリモートノードの要件を追加します。書き込みごとにクロスロケーションのラウンドトリップ時間を犠牲にして、完全なロケーション障害が発生してもデータが生き残ることを保証します。

MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT AND ANY 1 NOT ORIGIN_GROUP SYNCHRONOUS COMMIT

遅延制御 - フルスピードでローカルにコミットしますが、リモート遅延が構成されたしきい値を超える場合、トランザクションを調整します。同期確認を必要とせずに、リモート場所が大幅に遅延するのを防ぎます。

MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT AND ALL NOT ORIGIN_GROUP LAG CONTROL (max_lag_time = 30s)

クォーラムコミットスコープの作成#

クォーラムコミットでは、ノードがコミットする前にすべての参加ノードが同意する必要があります。他のコミットスコープの種類とは異なり、DEGRADE TO はサポートされておらず、熱心な競合解決は常にアクティブです。 ABORT ON 句は必須です。

SELECT bdr.create_commit_scope(
    commit_scope_name := quorum_scope,
    origin_node_group := <top_group>,
    rule := MAJORITY ORIGIN GROUP QUORUM COMMIT ABORT ON (timeout = 6s),
    wait_for_ready := true
);

マルチリージョンクラスターの場合、 MAJORITY FOR EACH GROUP IN CLUSTER を使用して、各サブグループ内のマジョリティを必要とします。トポロジに適切な構成を選択するためのガイダンスについては、 How Quorum Commit works を参照してください。

CAMOスコープの作成#

CAMOを使用している場合、ルールはSYNCHRONOUS COMMIT の代わりにCAMO キーワードを使用します。 CAMO、トランザクションの結果を追跡する同じサブグループ内の指定されたパートナーノードが必要です。したがって、コミット中に元のノードが失敗した場合、アプリケーションはパートナーを照会して、トランザクションが適用されたかどうかを判断できます。

SELECT bdr.create_commit_scope(
    commit_scope_name := camo_scope,
    origin_node_group := <location_a>,
    rule := ALL (<location_a>) CAMO DEGRADE ON (timeout=30s, require_write_lead=true) TO ASYNC,
    wait_for_ready := true
);

require_write_lead=true オプションは、ノードが現在の書き込みリーダーでない限り、非同期への低下を防ぎます。これがないと、非リーダーノードはタイムアウトで低下してローカルにコミットする可能性があり、書き込みリーダーがまだ起動していて、同じグループ内の書き込みを受け入れている場合、データ損失のリスクがあります。

CAMOは、他のコミットスコープ種類よりもオーバーヘッドが高く、フェールオーバー後のトランザクションの解決を処理するにはアプリケーションの変更が必要です。詳細については、 Commit At Most Once を参照してください。

デフォルトのコミットスコープの設定#

各サブグループのデフォルトとしてコミットスコープを設定して、その場所から発生するすべてのトランザクションに自動的に適用します。

SELECT bdr.alter_node_group_option(
    node_group_name := <location_a>,
    config_key := default_commit_scope,
    config_value := majority_protect
);

SELECT bdr.alter_node_group_option(
    node_group_name := <location_b>,
    config_key := default_commit_scope,
    config_value := majority_protect
);

重要

クォーラムコミットは、それを使用するトランザクションが、使用しないトランザクションと同じテーブルで同時に実行される場合、一貫性を保証しません。ノードグループにデフォルトのコミットスコープを設定すると、すべてのトランザクションが一貫性の利点を得ることができます。

グループ構成を変更せずに、特定のセッションまたはトランザクションのデフォルトをオーバーライドできます。

- - Session-level override
SET bdr.commit_scope = majority_protect;

- - Transaction-level override
BEGIN;
SET LOCAL bdr.commit_scope = camo_scope;
- - ...
COMMIT;

構成の検証#

各サブグループに正しいデフォルトのコミットスコープがあることを確認します。

SELECT node_group_name, default_commit_scope
FROM bdr.node_group_summary;

コミットスコープルールを確認します。

SELECT commit_scope_name, commit_scope_origin_node_group, commit_scope_rule
FROM bdr.commit_scopes;

現在のセッションのアクティブなコミットスコープを確認します。

SHOW bdr.commit_scope;

CAMOを使用している場合、パートナーノードに依存する前に、パートナーノードが接続され準備ができていることを確認します。

SELECT bdr.is_camo_partner_connected();
SELECT bdr.is_camo_partner_ready();

よくある落とし穴の回避#

運用ワークロードにはマジョリティ保護を使用します。 ローカル保護は、他のノードを待機せずにコミットします。レプリケーションが完了する前にノードに障害が発生すると、データが損失します。
高遅延の接続には、遅延制御を備えたローカル耐久性を使用します。 すべてのトランザクションでリモート確認を待機すると、クロスロケーションの遅延が高い場合、書き込みタイムアウトが発生します。
混合ワークロードには複数のスコープを使用します。 非クリティカルな書き込みは、クリティカルな書き込みと同じ遅延コストを支払うべきではありません。強力な耐久性保証を必要としないワークロードのセッションまたはトランザクションレベルでオーバーライドします。
2場所展開の場合、3番目の場所に監視ノードを追加します。 これがないと、ロケーションを失うとRaftクォーラムが破損し、クラスターは書き込みリーダーを選択できなくなります。
重複したトランザクションを許容できないワークロードには、 CAMOを使用します。 これがないと、コミット中にノードに障害が発生すると、フェールオーバー後にトランザクションが2回適用される場合があります。
クォーラムコミットでのシリアル化エラーを予期します。 迅速な競合解決は、コミットフェーズ中に2つの競合するトランザクションのいずれかを中止します。シリアル化エラーをキャッチして再試行するようにアプリケーションを構成します。