Eager conflict resolution
=========================

Eager競合解決Eager Replicationとしても知られ、
COMMIT決定プロセス中にシリアル化可能なエラーで互いに競合するトランザクションをアボートすることにより、競合を防止します。

 :ref:`グループコミット <グループコミット>` の競合解決オプションの1つとして
 :ref:`コミットスコープ <コミットスコープ>` を使用して構成します。

使用法
------

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

.. code:: sql

   BEGIN;

   SET LOCAL bdr.commit_scope = eager_scope;

   ... other commands possible...

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

.. code:: sql

   COMMIT;

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

.. code:: sql

   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
   );

..  note Upgrading?::
   古い`global` コミットスコープはもう存在しません。上記のコマンドは、 `bdr.global_commit_timeout` を`60s` に設定した古い`global` スコープと同じスコープを作成します。

Eager競合解決ルールのコミットスコープグループは、\ ``ALL``
または\ ``MAJORITY`` のみです。 ``ALL`` を使用する場合、
``commit_decision`` 設定も\ ``raft`` に設定する必要があります。

エラー処理
----------

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

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

Eager Replicationの効果一般
---------------------------

アボート率の増加
^^^^^^^^^^^^^^^^

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

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

MAJORITYおよびALLノードレプリケーション一般の効果
-------------------------------------------------

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

コミットスコープの使用により同期ステップを追加すると、ノード間の通信が増加し、コミット時のレイテンシーが増加することを意味します。コミットスコープでALLが使用される場合、ノードがダウンするとトランザクションが失敗するため、システムの可用性が低下することも意味します。

1つ以上のノードが遅延している場合、確認を取得する際の往復遅延が大きくなり、高遅延が発生する可能性があります。
ALLまたはMAJORITYノードレプリケーションでは、約2つのネットワークラウンドトリップ、最悪の場合、最も遠いピアノードまでが追加されます。論理スタンバイノードと、まだ参加またはキャッチアップ中のノードは含まれませんが、最終的に変更を受け取ります。

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