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