このセクションでは、MySQL Group Replication のバックグラウンド情報を提供します。

フォルトトレラントシステムを作成する最も一般的な方法は、コンポーネントを冗長にすることです。つまり、コンポーネントを削除でき、システムは引き続き予想どおりに動作する必要があります。 これにより、このようなシステムの複雑さを異なるレベル全体に引き上げる一連の課題が作成されます。 具体的には、レプリケートされたデータベースは、1 つのサーバーではなく複数のサーバーのメンテナンスおよび管理が必要であるという事実に対処する必要があります。 さらに、サーバーが連携してグループを作成しているため、ネットワークのパーティション化やスプリットブレーンシナリオなど、他のいくつかのクラシック分散システムの問題を処理する必要があります。

したがって、最終的な課題は、データベースおよびデータレプリケーションのロジックを、一貫性のある簡単な方法で複数のサーバーを調整するロジックと融合することです。 つまり、複数のサーバーがシステムの状態と、システムが通過する各変更のデータに同意するようにします。 これは、すべてが単一のデータベースとして進行するように、または最終的に同じ状態に収束するように、サーバーが各データベースの状態遷移で承諾に到達するように要約できます。 つまり、(分散) 状態マシンとして動作する必要があります。

MySQL Group Replication は、サーバー間で強力に調整された分散状態マシンのレプリケーションを提供します。 サーバーは、同じグループの一部である場合に自動的に調整されます。 グループは、一度に 1 つのサーバーのみが更新を受け入れる自動プライマリ選択を使用して、単一プライマリモードで動作できます。 または、より上級のユーザーの場合は、グループをマルチプライマリモードでデプロイできます。マルチプライマリモードでは、同時に発行された場合でも、すべてのサーバーが更新を受け入れることができます。 この機能は、このようなデプロイメントによって課される制限を回避する必要があるアプリケーションを犠牲にします。

グループのビューの一貫性を保ち、任意の時点ですべてのサーバーで使用できるようにする組込みグループメンバーシップサービスがあります。 サーバーはグループから退出して参加でき、それに応じてビューが更新されます。 サーバーが予期せずにグループから離れる場合があります。その場合、障害検出メカニズムはこれを検出し、ビューが変更されたことをグループに通知します。 これはすべて自動です。

トランザクションをコミットするには、グループの大部分が、トランザクションのグローバル順序での特定のトランザクションの順序に合意する必要があります。 トランザクションをコミットまたは中断するかどうかは、各サーバーによって個別に決定されますが、すべてのサーバーが同じ決定を行います。 ネットワークパーティションがあり、メンバーがアグリーメントに到達できない分割になった場合、この問題が解決されるまでシステムは進行しません。 したがって、ビルトインの自動スプリットブレイン保護メカニズムもあります。

これらはすべて、提供されている Group Communication System (GCS) プロトコルによって処理されます。 これらは、障害検出メカニズム、グループメンバーシップサービス、および安全で完全に順序付けされたメッセージ配信を提供します。 これらのプロパティはすべて、サーバーのグループ間でデータが一貫してレプリケートされるようにするシステムの作成に重要です。 このテクノロジの非常にコアには、Paxos アルゴリズムの実装があります。 グループ通信エンジンとして機能します。