目录
MySQL InnoDB ClusterSet 通过将主 InnoDB Cluster 与其在备用位置（例如不同数据中心）的一个或多个副本链接起来，为 InnoDB Cluster 部署提供容灾能力。InnoDB ClusterSet 使用专用的 ClusterSet 复制通道自动管理从主集群到副本集群的复制。如果主集群由于数据中心丢失或与它的网络连接丢失而变得不可用，您可以激活副本集群来恢复服务的可用性。有关部署 InnoDB 集群的信息，请参阅 第 7 章，MySQL InnoDB集群。
InnoDB ClusterSet 部署中主 InnoDB Cluster 和副本集群之间的紧急故障转移可以由管理员通过 MySQL Shell（参见 MySQL Shell 8.0），使用 AdminAPI（参见 第 6.1 节，“使用 MySQL AdminAPI”）触发，它包含在MySQL 外壳。您还可以在主集群仍然可用时执行从主集群到副本集群的受控切换，例如，如果需要对主集群进行配置更改或维护。MySQL Router（参见 MySQL Router 8.0）自动将客户端应用程序路由到 InnoDB ClusterSet 部署中的正确集群。
InnoDB ClusterSet 部署中的副本集群在保持被动副本时不能与主集群分离，因为它不接受写入。它可以被应用程序读取，尽管应该预料到异步复制的典型复制滞后量，因此数据可能还不完整。副本集群的最小大小是单个成员服务器实例，但建议至少包含三个成员以实现容错。如果需要更多成员，例如因为副本集群已通过切换或故障转移成为主集群，您可以随时使用 AdminAPI 通过 MySQL Shell 添加更多实例。InnoDB ClusterSet 部署中可以拥有的副本集群的数量没有定义的限制。
下图中的示例 InnoDB ClusterSet 部署包括罗马数据中心的主 InnoDB 集群，以及里斯本和布鲁塞尔数据中心的副本集群。主集群及其副本集群各包含三个成员服务器实例，一个主服务器实例和两个辅助服务器实例。
异步复制通道将事务从主集群复制到副本集群。clusterset_replication在 InnoDB ClusterSet 创建过程中，在每个集群上设置了名为 ClusterSet 的复制通道，当集群是副本时，它使用该通道从主集群复制事务。底层组复制技术管理通道并确保复制始终在主集群的主服务器（作为发送方）和副本集群的主服务器（作为接收方）之间进行。如果为主集群或副本集群选择了新的主集群，则 ClusterSet 复制通道会在它们之间自动重新建立。
尽管示例 InnoDB ClusterSet 部署中的每个集群都有一个主 MySQL 服务器，但只有主 InnoDB 集群的主服务器接受来自客户端应用程序的写入流量。副本集群没有。MySQL Router 实例将所有写入流量路由到罗马数据中心的主集群，由主服务器处理。大多数读取流量也被路由到主集群，但只发出读取请求的报告应用程序被专门路由到其本地数据中心的副本集群，以节省网络资源。请注意，处理读写流量的 MySQL Router 实例被设置为将流量路由到 InnoDB ClusterSet 中的主 InnoDB Cluster，无论是哪个。
重要的是要知道 InnoDB ClusterSet 将可用性优先于数据一致性，以最大限度地提高容灾能力。每个单独的 InnoDB Cluster 内的一致性由底层的 组复制技术保证。但是，正常的复制滞后或网络分区可能意味着在主集群遇到问题时，部分或所有副本集群与主集群不完全一致。在这些情况下，如果您触发紧急故障转移，任何未复制或不同的事务都有丢失的风险，并且只能手动恢复和协调（如果它们可以访问的话）。无法保证在发生紧急故障转移时会保留数据。
因此，在触发紧急故障转移之前，您应该始终尝试修复或重新连接主集群。AdminAPI 消除了直接使用 Group Replication 来修复 InnoDB Cluster 的需要。如果主集群无法足够快地修复或无法访问，您可以继续紧急故障转移到副本 InnoDB 集群，以恢复应用程序的可用性。在受控的切换过程中，数据一致性得到保证，原始主集群降级为工作的只读副本集群。但是，在紧急故障转移过程中，数据的一致性是无法保证的，所以为了安全起见，在故障转移过程中，原主集群被标记为失效。如果原来的主集群保持在线，
如果没有问题并且事务集与拓扑中的其他集群一致，您可以在之后将无效的主集群重新加入到 InnoDB ClusterSet 拓扑中。检查、恢复和重新加入失效的主集群不会自动发生——管理员需要使用 AdminAPI 命令来执行此操作。您可以选择修复失效的主集群并使其重新上线，也可以丢弃原来的主集群，继续使用新的主集群作为主集群，并创建新的副本集群。