Eager conflict resolution¶

積極的な競合解決（積極的なEager Replicationとも呼ばれます）は、 COMMIT 決定プロセス中にシリアル化可能なエラーで互いに競合するトランザクションを中止することにより、競合を防ぎます。

Group Commit の競合解決オプションの1つとして commitスコープへの移行

を使用して構成します。

使用法¶

Eager競合解決を有効にするには、クライアントはコミットスコープに切り替える必要があります。これは、次に示すように、セッションレベルまたは個々のトランザクションで使用します。

BEGIN;

SET LOCAL bdr.commit_scope = eager_scope;

... other commands possible...

クライアントは、トランザクションの最後にCOMMIT の発行を継続し、PGDに2つのフェーズを管理させることができます。

COMMIT;

この場合、 eager_scope コミットスコープは次のように定義されます。

SELECT bdr.add_commit_scope(
    commit_scope_name := eager_scope,
    origin_node_group := top_group,
    rule := ALL (top_group) GROUP COMMIT (conflict_resolution = eager, commit_decision = raft) ABORT ON (timeout = 60s),
    wait_for_ready := true
);

エラー処理¶

PGDがトランザクションを管理することを考えると、クライアントはCOMMIT の結果のみを確認する必要があります。これは、シングルノードのPostgresを含む、どのような場合でもお勧めします。

起点ノードに障害が発生した場合、残りのノードは最終的に（少なくともABORT ON timeout の後）、グローバルに準備されたトランザクションをロールバックすることを決定します。 Raftは、一貫性のないコミットとロールバックの決定を防ぎます。ただし、これには接続されたノードの大部分が必要です。切断されたノードは、必要に応じてトランザクションを最終的にコミット（またはロールバック）する準備を整え、決定してさらに進んだ可能性のあるノードの大部分と調整します。

一般的な積極的なEager Replicationの効果¶

コミットレイテンシーの増加¶

同期ステップを追加するということは、ノード間の通信が増えることを意味し、その結果、コミット時の待機時間が長くなります。 Eager All-Node Replicationは、約2つのネットワークラウンドトリップを追加します（最悪の場合、最も遠いピアノードへ）。ロジカルスタンバイノードと、まだ参加中またはキャッチアップ中のノードは含まれませんが、最終的に変更を受け取ります。

ピアノードがトランザクションのローカル準備を確認できる前に、ローカルに適用する必要もあります。これにより、トランザクションのサイズによっては、コミットレイテンシーがさらに増加します。この設定は、 synchronous_commit 設定とは無関係です。

中止率の増加¶

シングルノードPostgres、またはデフォルトの非同期レプリケーションモードのPGDを使用しても、 COMMIT 時のエラーはまれです。追加された同期ステップによりエラーのソースが追加されるため、アプリケーションはこのようなエラーを適切に処理する準備をする必要があります（通常は再試行ループを適用することにより）。

アボートの割合は、ワークロードのみに依存します。多くの行を変更する大規模なトランザクションは、他の同時実行トランザクションと競合する可能性がはるかに高くなります。