分散一貫性保証では、通常の修復操作または障害修復操作のいずれかにおいて、グループレプリケーションは常に最終的な一貫性システムでした。 つまり、受信トラフィックの速度が低下または停止するとすぐに、すべてのグループメンバーのデータコンテンツが同じになります。 システムの整合性に関連するイベントは、手動または障害によって自動的にトリガーされる制御操作と、データフロー操作に分割できます。
グループレプリケーションの場合、一貫性の観点から評価できる制御操作は次のとおりです:
グループレプリケーション セクション18.4.3「分散リカバリ」 および書込み保護でカバーされるメンバーの参加または離脱。
ネットワーク障害。フェンシングモードでカバーされます。
単一プライマリグループのプライマリフェイルオーバー (
group_replication_set_as_primary()によってトリガーされる操作の場合もあります)。
単一プライマリグループでは、セカンダリがプライマリに昇格されたときにプライマリフェイルオーバーが発生した場合、レプリケーションバックログの大きさに関係なく、新しいプライマリをアプリケーショントラフィックですぐに使用可能にすることも、バックログが適用されるまでアクセスを制限することもできます。
最初のアプローチでは、新しいプライマリを選択し、古いプライマリから可能性のあるバックログをまだ適用している間にデータアクセスをすぐに許可することで、プライマリの障害後に安定したグループメンバーシップを保護できる最小時間がグループにかかります。 書込み一貫性は保証されますが、読取りでは、新しいプライマリがバックログを適用している間、失効したデータを一時的に取得できます。 たとえば、クライアント C1 が障害の直前に古いプライマリに A=2 WHERE A=1 を書き込んだ場合、クライアント C1 が新しいプライマリに再接続されると、新しいプライマリがバックログを適用してグループを離れる前の古いプライマリの状態でキャッチアップするまで、A=1 を読み取る可能性があります。
2 つ目の代替方法では、プライマリ障害後に安定したグループメンバーシップが保護され、最初の代替方法と同じ方法で新しいプライマリが選択されますが、この場合、グループは新しいプライマリがすべてのバックログを適用するまで待機してから、データアクセスを許可します。 これにより、前述のような状況で、クライアント C1 が新しいプライマリに再接続されると、A=2 が読み取られます。 ただし、フェイルオーバーに必要な時間はバックログのサイズに比例するため、適切に構成されたグループでは小さいにする必要があります。
MySQL 8.0.14 より前は、フェイルオーバーポリシーを構成する方法はありませんでした。デフォルトでは、可用性は最初のアプローチで説明されているように最大化されていました。 MySQL 8.0.14 以上を実行しているメンバーがいるグループでは、group_replication_consistency 変数を使用して、プライマリフェイルオーバー時にメンバーによって提供されるトランザクション一貫性保証のレベルを構成できます。 プライマリ選択に対する整合性の影響を参照してください。
データフローは、特にこれらの操作がすべてのメンバーに分散されている場合に、グループに対して実行される読取りおよび書込みによるグループの一貫性保証に関連します。 データフロー操作は、グループレプリケーションの両方のモードに適用されます: ただし、この説明を明確にするために、シングルプライマリモードとマルチプライマリモードに制限されています。 単一プライマリグループメンバー間で受信読取りまたは書込みトランザクションを分割する通常の方法は、書込みをプライマリにルーティングし、読取りをセカンダリに均等に分散することです。 グループは単一のエンティティとして動作する必要があるため、プライマリでの書込みがセカンダリで即時に使用可能であることを期待することが妥当です。 Group Replication は Paxos アルゴリズムを実装する Group Communication System (GCS) プロトコルを使用して記述されますが、Group Replication の一部は非同期であり、これはデータがセカンダリに非同期に適用されることを意味します。 これは、クライアント C2 がプライマリに B=2 WHERE B=1 を書き込んで、すぐにセカンダリに接続し、B=1 を読み取ることができることを意味します。 これは、セカンダリがまだバックログを適用しており、プライマリによって適用されたトランザクションを適用していないためです。
グループ全体でトランザクションを同期する時点に基づいて、グループの一貫性保証を構成します。 このセクションでは、概念を理解しやすくするために、読取り操作時または書込み操作時にグループ全体でトランザクションを同期するポイントを簡略化します。 読取り時にデータが同期化された場合、現在のクライアントセッションは、特定の時点 (前のすべての更新トランザクションが適用された時点) まで待機してから、実行を開始します。 このアプローチでは、このセッションのみが影響を受け、他のすべての同時データ操作は影響を受けません。
書き込み時にデータが同期された場合、書き込みセッションはすべてのセカンダリがデータを書き込むまで待機します。 グループレプリケーションでは書込みの合計順序が使用されるため、これは、セカンダリのキューにあるこの書込みおよびそれより前のすべての書込みが適用されるのを待機していることを意味します。 したがって、この同期ポイントを使用する場合、書き込みセッションはすべてのセカンダリキューが適用されるまで待機します。
代替方法により、クライアントに説明されている状況では、すぐにセカンダリに接続されていても、C2 は常に B=2 を読み取るようになります。 それぞれの代替方法には、システムワークロードに直接関連する利点とデメリットがあります。 次の例では、様々なタイプのワークロードについて説明し、適切な同期ポイントをアドバイスします。
次の状況を考えてみます:
失効したデータの読取りを回避するために、読取り元のサーバーに追加の制限をデプロイせずに読取りのロードバランシングを行う場合、グループ書込みはグループ読取りよりもはるかに一般的ではありません。
主に読取り専用データを持つグループがある場合、コミットされたすべての場所に読取り/書込みトランザクションを適用して、最新の書込みを含む最新のデータに対して後続の読取りが実行されるようにします。 これにより、すべての RO トランザクションに対して同期コストを支払うのではなく、RW トランザクションに対してのみ支払うようになります。
このような場合は、書込み時に同期化することを選択する必要があります。
次の状況を考えてみます:
失効したデータの読取りを回避するために、読取り元のサーバーに追加の制限をデプロイせずに読取りのロードバランシングを行う場合、グループ書込みはグループ読取りよりもはるかに一般的です。
ワークロード内の特定のトランザクションで、機密データ (ファイルの資格証明や類似データなど) が更新され、読取りで最新の値が取得されるように強制する場合などに、常にグループから最新のデータを読み取る必要があります。
このような場合は、読取り時に同期化することを選択する必要があります。