MySQL 8.4 Release Notes
20.1.2 组复制用例
组复制使您可以创建具有冗余的系统，以便在服务器故障时保持系统状态的一致性。即使一些服务器随后失败，也只要不是所有或大多数，系统仍然可用。根据服务器数量的变化，组可能会出现性能下降或扩展性下降，但仍然可用。服务器故障是孤立的和独立的。它们由一个分布式成员服务跟踪，该服务依赖于一个分布式故障检测器，可以在任何服务器离开组时（无论是自愿还是由于意外中止）发出信号。有一个分布式恢复程序，以确保当服务器加入组时，它们将自动更新到最新状态。没有必要进行服务器故障转移，多源更新的性质确保了即使在单个服务器故障的情况下，也不会阻塞更新。总之，MySQL 组复制保证数据库服务始终可用。
需要注意的是，即使数据库服务可用，在意外服务器退出事件中，连接到该服务器的客户端必须被重新定向或失败转移到其他服务器。这不是组复制尝试解决的问题。连接器、负载均衡器、路由器或某种形式的中间件更适合处理这个问题。例如，请见 MySQL Router 8.4。
总之，MySQL 组复制提供了一个高度可用的、高度弹性的、可靠的 MySQL 服务。
Tip
要部署多个MySQL实例，可以使用InnoDB集群，它使您可以轻松地管理一组MySQL服务器实例在MySQL Shell中。 InnoDB集群将MySQL Group Replication包装在一个程序化环境中，使您可以轻松部署多个MySQL实例以实现高可用性。此外，InnoDB集群与MySQL Router无缝接口，您的应用程序可以连接到集群而不需要编写自己的故障转移过程。对于类似的用例，但不需要高可用性，可以使用InnoDB ReplicaSet。MySQL Shell的安装指南可以在这里找到。
以下是一些Group Replication的典型用例。
-
弹性复制 - 需要非常灵活的复制基础结构的环境，其中服务器数量需要动态增长或缩小，并且尽量减少副作用。例如，云数据库服务。
-
高可用性分区 - 分区是实现写入扩展的一种流行方法。使用MySQL Group Replication来实现高可用性分区，每个分区映射到一个复制组。
-
异步源-副本复制的替代方案 - 在某些情况下，使用单个源服务器会使其成为一个瓶颈。将写入整个组可能在某些情况下证明更具可扩展性。
-
自适应系统 - 另外，您还可以纯粹地部署 MySQL Group Replication，以便利用复制协议中的自动化功能（如前几章中已经描述的那样）。