【第 8 章 MySQL InnoDB ClusterSet 】

文章目录

• 【第 8 章 MySQL InnoDB ClusterSet 】
• • 本章内容
  • 本章简介

本章内容

8.1 InnoDB ClusterSet 要求
8.2 InnoDB ClusterSet 限制
8.3 User Accounts for InnoDB ClusterSet
8.4 Deploying InnoDB ClusterSet
8.5 Integrating MySQL Router With InnoDB ClusterSet
8.6 InnoDB ClusterSet Status and Topology
8.7 InnoDB ClusterSet Controlled Switchover
8.8 InnoDB ClusterSet Emergency Failover
8.9 InnoDB ClusterSet Repair and Rejoin
8.10 Upgrade InnoDB ClusterSet

本章简介

MySQL InnoDB ClusterSet 通过将主 InnoDB Cluster 与位于不同位置（例如不同的数据中心）的一个或多个副本链接起来，为 InnoDB Cluster 部署提供了容灾能力。InnoDB ClusterSet 使用专用 ClusterSet 复制通道自动管理从主集群到副本集群的复制。如果主群集由于数据中心丢失或与之失去网络连接而变得不可用，则可以将副本群集激活以恢复服务的可用性。有关部署 InnoDB Cluster的信息，请参阅 第7章 MySQL InnoDB Cluster 。

InnoDB ClusterSet 部署中的主 InnoDB 集群和副本集群之间的紧急故障切换可由管理员通过 MySQL Shell ，使用 MySQL Shell 附带的 AdminAPI（参见 第6.1节 “使用MySQL AdminAPI”）触发。您还可以在主群集仍然可用时（例如，如果需要对主群集进行配置更改或维护），执行从主群集到副本群集的受控切换。MySQL Router 自动将客户端应用程序路由到 InnoDB ClusterSet 部署中的正确集群。

InnoDB ClusterSet 部署中的副本集群不能脱离主集群，而它仍然是被动副本，因为它不接受写入。它可以由应用程序读取，尽管异步复制通常会有一定的复制延迟，因此数据可能还不完整。副本群集的最小大小是单个成员服务器实例，但为了容错，建议至少三个成员。如果需要更多成员，例如，因为副本集群通过切换或故障切换成为主集群，您可以随时使用 AdminAPI 通过 MySQL Shell 添加更多实例。InnoDB ClusterSet 部署中可以拥有的副本集群数量没有定义的限制。

下图中的示例 InnoDB ClusterSet 部署包括位于罗马数据中心的主 InnoDB 集群，以及位于里斯本和布鲁塞尔数据中心的副本集群。主集群及其副本集群均由三个成员服务器实例组成，一个主服务器实例和两个辅助服务器实例。

图 8.1 InnoDB ClusterSet 概览

异步复制通道将事务从主集群复制到副本集群。在 InnoDB ClusterSet 创建过程中，会在每个集群上设置一个名为clusterset_replication的 ClusterSet 复制通道，当集群是副本时，它会使用该通道从主集群复制事务。底层组复制技术管理通道，并确保复制始终在主集群的主服务器（作为发送方）和副本集群的主要服务器（作为接收方）之间进行。如果为主集群或副本集群选择了新的主服务器，则会在它们之间自动重新建立 ClusterSet 复制通道。

尽管示例 InnoDB ClusterSet 部署中的每个集群都有一个主 MySQL 服务器，但只有主 InnoDB 集群的主服务器接受来自客户端应用程序的写入流量。副本群集不会。 MySQL 路由器实例将所有写入流量路由到罗马数据中心的主集群，由主服务器处理。大多数读取流量也会路由到主集群，但仅发出读取请求的报告应用程序会专门路由到其本地数据中心的副本集群，以节省网络资源。请注意，处理读写流量的 MySQL Router 实例被设置为将流量路由到 InnoDB ClusterSet 中的主 InnoDB 集群，无论是哪一个。因此，如果其他集群中的一个在受控切换或紧急故障切换后成为主集群，则这些 MySQL Router 将将流量路由至该集群。

重要的是要知道 InnoDB ClusterSet 将可用性优先于数据一致性，以最大限度地提高容灾能力。每个 InnoDB 集群内的一致性由底层组复制技术保证。但是，正常的复制延迟或网络分区可能意味着在主群集遇到问题时，一些或所有副本群集与主群集不完全一致。在这些情况下，如果您触发紧急故障切换，任何未复制或不同的事务都有丢失的风险，只能手动恢复和协调（如果可以访问）。无法保证在发生紧急故障切换时数据会被保留。

因此，在触发紧急故障切换之前，应始终尝试修复或重新连接主群集。 AdminAPI 消除了直接使用 Group Replication 修复 InnoDB 群集的需要。如果无法快速修复主集群或无法访问主集群，您可以继续紧急故障切换到副本 InnoDB 集群，以恢复应用程序的可用性。在受控切换过程中，数据一致性得到保证，原始主集群降级为工作的只读副本集群。但是，在紧急故障切换过程中，无法保证数据的一致性，因此为了安全起见，在故障切换过程中将原始主群集标记为无效。如果原始主群集保持联机，则应在联系到它后立即关闭。

如果没有问题，并且事务集与拓扑中的其他集群一致，您可以在之后将失效的主集群重新加入 InnoDB ClusterSet 拓扑。检查、恢复和重新加入失效的主集群不会自动发生 - 管理员需要使用 AdminAPI 命令来执行此操作。您可以选择修复失效的主群集并使其重新联机，也可以放弃原始主群集，继续使用新的主群集作为主群集，并创建新的副本群集。