Group Commit¶
Group Commitの目的は、単一ノードの障害または一時的な停止が発生した場合のデータ損失から保護することです。これを行うには、COMMIT時にトランザクションを正常に受信して確認するために複数のBDRノードを要求します。
要件¶
通常の操作中、Group Commitはアプリケーションに対して完全に透過的です。フェールオーバー時に、調整フェーズは、アプリケーションまたは中間のプロキシによって明示的にトリガーまたは統合される必要があります。 HARPはグループコミットのネイティブサポートを提供し、調整フェーズをトリガーするため、これをクライアントに等しく透過的にします。
オリジンノードでは、グループコミットでコミットされたトランザクションは、下で2フェーズコミットを使用します。したがって、ノードごとに発生するそのようなすべてのトランザクションを処理するのに十分な高さにmax_prepared_transactions
を構成します。
構成¶
Group Commitを使用するには、最初にcommitスコープを定義します。これにより、トランザクションのコミットに関係するBDRノードが決まります。スコープを確立したら、次のようにGroup Commitを使用するようにトランザクションを構成できます。
BEGIN;
SET LOCAL bdr.commit_scope = example_scope;
...
COMMIT;
この例では、以前にコミットスコープを次のように定義している可能性があります。
SELECT bdr.add_commit_scope(
commit_scope_name := example_scope,
origin_node_group := example_bdr_group,
rule := ANY 2 (example_bdr_group)
);
これは、 example_bdr_group
という名前のノードグループが存在し、少なくとも2つのBDRノードをメンバーとして直接またはサブグループに含むことを前提としています。
example_scope
でコミットされたトランザクションには、グループ内のBDRノードからの追加の確認が1つ必要です。起点ノードとともに、これはグループ外の「ANY
2」ノードを説明し、トランザクションはコミット後の可視性と持続性が保証されます。
オリジングループ¶
コミットスコープのルールは、トランザクションがコミットされるノード、つまりトランザクションのオリジンとして機能するノードによって異なります。これをアプリケーションに対して透過的にするために、 BDRでは、トランザクションの発生元に応じてコミットスコープがさまざまなルールを定義できます。
たとえば、ノードが左側と右側の2つのデータセンターにまたがるEDB
Postgres分散クラスターを考えます。最上位のBDRノードグループの名前がtop_group
であるとします。次のコマンドを使用して、サブグループを設定し、ローカルデータセンター内のすべてのノードがトランザクションを確認しますが、リモートからは1つのノードのみを確認するコミットスコープを作成できます。
- - create sub-groups
SELECT bdr.create_node_group(
node_group_name := left_dc,
parent_group_name := top_group,
join_node_group := false
);
SELECT bdr.create_node_group(
node_group_name := right_dc,
parent_group_name := top_group,
join_node_group := false
);
- - create a commit scope with individual rules
- - for each sub-group
SELECT bdr.add_commit_scope(
commit_scope_name := example_scope,
origin_node_group := left_dc,
rule := ALL (left_dc) AND ANY 1 (right_dc)
);
SELECT bdr.add_commit_scope(
commit_scope_name := example_scope,
origin_node_group := right_dc,
rule := ANY 1 (left_dc) AND ALL (right_dc)
);
確認レベル¶
BDRノードは、 Commit At Most Once と同様に、さまざまな時点でトランザクションの確認を送信できます。保護レベルを高めると、確認ノードの観点から、これらは次のとおりです。
received—リモートBDRノードは、ローカルアプリケーションを起動する前に、トランザクションを受信した直後に確認します。replicated—トランザクションの変更を適用した後、ディスクにフラッシュする前に確認します。durable—すべての変更がディスクにフラッシュされた後、トランザクションを確認します。visible(デフォルト)すべての変更がディスクにフラッシュされ、同時実行トランザクションから見えるようになったら、トランザクションを確認します。
コミットスコープのルールでは、次のようにON
を使用して、これらの確認レベルを括弧内のノードグループ定義に追加できます。
ANY 2 (right_dc) ON replicatedALL (left_dc) ON visible(デフォルトで省略可)ALL (left_dc) ON received AND ANY 1 (right_dc) ON durable
リファレンス¶
コミットスコープの文法¶
参考までに、コミットスコープの文法は次のように構成されています。
commit_scope:
confirmation [AND ...]
confirmation:
node_def (ON [received|replicated|durable|visible])
node_def:
ANY num (node_group [, ...])
| MAJORITY (node_group [, ...])
| ALL (node_group [, ...])
注釈
synchronous_standby_names とコミットスコープの文法は非常に似ていますが、前者は起点ノードを考慮しないことに注意することが重要です。したがって、たとえば synchronous_standby_names = 'ANY 1 (..)' は`ANY 2 (...)` のコミットスコープと同等です。この選択により、多数決についての推論が容易になり、オリジンノードがトランザクションの耐久性と可視性にも寄与することを反映しています。
コミットスコープルールの追加¶
ファンクションbdr.add_commit_scope
は、指定されたコミットスコープ名とオリジンノードグループのルールを作成します。
EDB
Postgres分散クラスター内のすべてのノードでルールが同じ場合、最上位ノードグループに対してこの関数を1回呼び出すだけで、コミットスコープを完全に定義できます。
または、同じ commit_scope_name
で複数回呼び出すことができますが、トランザクションの起点によって異なる起点ノードグループとコミットスコープのルールが異なります。
概要¶
bdr.add_commit_scope(
commit_scope_name NAME,
origin_node_group NAME,
rule TEXT)
コミット範囲ルールの変更¶
コミットスコープ内の単一のオリジンノードグループの特定のルールを変更するには、ファンクションbdr.alter_commit_scope
を使用できます。
概要¶
bdr.alter_commit_scope(
commit_scope_name NAME,
origin_node_group NAME,
rule TEXT)
コミットスコープルールの削除¶
bdr.remove_commit_scope
を使用して、コミット範囲内の単一のルールを削除できます。コミットスコープに複数のルールを定義する場合、ルールごとに1回このファンクションを呼び出して、コミットスコープ全体を完全に削除する必要があります。
概要¶
bdr.remove_commit_scope(
commit_scope_name NAME,
origin_node_group NAME)
注釈
ノードグループによってまだデフォルトとして使用されているコミットスコープを削除することは許可されていません