グループレプリケーションでは、グループ内の大部分のメンバーがトランザクションを受信し、同時に送信されたすべてのトランザクション間の相対的な順序で合意した後にのみ、トランザクションがコミットされます。 この方法は、グループへの書込みの合計数がグループ内のどのメンバーの書込み容量も超えない場合に適しています。 書込みスループットが他のメンバーよりも低い場合 (特にライターメンバーよりも低い場合)、これらのメンバーはライターの遅延を開始できます。
一部のメンバーがグループより遅れていると、問題のある結果が発生します。特に、このようなメンバーに対する読取りによって、非常に古いデータが外部化される可能性があります。 メンバーが遅れている理由によっては、低速メンバーからの潜在的なデータ転送リクエストを満たすために、グループ内の他のメンバーがより多くのレプリケーションコンテキストを保存する必要がある場合があります。
ただし、レプリケーションプロトコルには、高速メンバーと低速メンバーの間に適用されるトランザクションに関して距離が多すぎることを回避するメカニズムがあります。 これはフロー制御メカニズムと呼ばれます。 いくつかの目標に対処しようとします:
メンバー間でバッファリングおよび同期解除を行うのに十分な大きさにメンバーを近づけることは、小さい問題です
グループ内の異なるワークロードやより多くのライターなどの条件の変化に迅速に適応できます
各メンバーに使用可能な書込み容量のフェアシェアを付与
リソースの無駄を避けるために必要以上のスループットを削減しません。
グループレプリケーションの設計では、2 つの作業キューを考慮してスロットルするかどうかを決定できます: 動作保証キュー、(ii) およびバイナリログ applier キューで (i) を実行します。 これらのキューのいずれかのサイズがユーザー定義のしきい値を超えると、スロットルメカニズムがトリガーされます。 構成のみ: (i) では、認証者レベルまたはアプライヤレベル (あるいはその両方) でフロー制御を実行するかどうか、および (ii) では各キューのしきい値は何ですか。
フロー制御は、次の 2 つの基本メカニズムに依存します:
すべてのグループメンバーのスループットおよびキューサイズに関するいくつかの統計を収集するためのメンバーの監視。各メンバーの最大書込み圧力を測定
各時点で使用可能な容量の公平配分を超えて書き込もうとしているメンバーのスロットル。