Group Replication を使用すると、システム状態を一連のサーバーにレプリケートすることで、冗長性を備えたフォルトトレラントシステムを作成できます。 その後、一部のサーバーで障害が発生した場合でも、すべてでないか大部分であるかぎり、システムは引き続き使用可能です。 グループに障害が発生したサーバーの数によっては、パフォーマンスまたはスケーラビリティが低下する可能性がありますが、まだ使用可能です。 サーバー障害は分離され、独立しています。 これらは、任意のサーバーがグループから退出したときに通知できる分散障害検出機能に依存するグループメンバーシップサービスによって追跡されます (自発的または予期しない停止のため)。 サーバーがグループに参加したときに自動的に最新の状態になるようにする分散リカバリ手順があります。 サーバーのフェイルオーバーは必要ありません。また、マルチソース更新では、単一のサーバーに障害が発生した場合にも更新がブロックされないように、あらゆる性質があります。 要約すると、MySQL Group Replication では、データベースサービスが継続的に使用可能であることが保証されます。
データベースサービスは使用可能ですが、予期しないサーバーの終了時には、接続しているクライアントを別のサーバーにリダイレクトまたはフェイルオーバーする必要があることを理解することが重要です。 これは Group Replication が解決しようとするものではありません。 コネクタ、ロードバランサ、ルーターまたはなんらかの形式のミドルウェアは、この問題の処理に適しています。 たとえば、MySQL Router 8.0 を参照してください。
要約すると、MySQL Group Replication は、可用性が高く、柔軟性の高い、信頼性の高い MySQL サービスを提供します。
MySQL の複数のインスタンスをデプロイするには、MySQL Shell で MySQL サーバーインスタンスのグループを簡単に管理できるようにする InnoDB クラスタ を使用できます。InnoDB クラスタ は MySQL Group Replication をプログラム環境でラップするため、MySQL インスタンスのクラスタを簡単にデプロイして高可用性を実現できます。 また、InnoDB クラスタ は MySQL Router とシームレスにインタフェースするため、アプリケーションは独自のフェイルオーバープロセスを記述せずにクラスタに接続できます。 ただし、高可用性を必要としない同様のユースケースでは、InnoDB ReplicaSet を使用できます。 MySQL Shell のインストール手順は、here にあります。
次に、グループレプリケーションの一般的なユースケースの例を示します。
エラスティックレプリケーション - 非常に流体的なレプリケーションインフラストラクチャを必要とする環境。サーバーの数は、可能なかぎり少ない副作用で動的に増加または縮小する必要があります。 たとえば、クラウドのデータベースサービスです。
高可用性シャード - シャーディングは、書込みスケールアウトを実現するための一般的なアプローチです。 MySQL Group Replication を使用して、各シャードがレプリケーショングループにマップされる高可用性シャードを実装します。
非同期ソース - レプリケーションレプリケーションの代替 - 特定の状況では、単一のソースサーバーを使用すると、単一の競合ポイントになります。 グループ全体への書込みは、特定の状況下でよりスケーラブルであることが証明される場合があります。
自律システム - また、レプリケーションプロトコルに組み込まれている自動化のためにのみ、MySQL Group Replication をデプロイできます (この章および前の章ですでに説明しています)。