Eager conflict resolution#
Eager競合解決Eager Replicationとしても知られ、 COMMIT決定プロセス中にシリアル化可能なエラーで互いに競合するトランザクションをアボートすることにより、競合を防止します。
使用法#
迅速な競合解決を有効にするには、クライアントをコミットスコープに切り替える必要があります。ここで示すように、セッションレベルまたは個々のトランザクションでそれを使用します。
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
時のエラーはほとんどありません。追加された同期手順はエラーのソースを追加するため、アプリケーションはこのようなエラーを適切に処理するように準備する必要があります通常は再試行ループを適用します。
アボートの率は、ワークロードにのみ依存します。多くの行を変更する大規模なトランザクションは、他の同時トランザクションと競合する可能性が非常に高くなります。