MySQL Shell 8.4  /  MySQL InnoDB ClusterSet

第 8 章 MySQL InnoDB ClusterSet

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

InnoDB ClusterSet 部署中主 InnoDB 集群与副本集群之间的紧急故障转移可以由管理员通过 MySQL Shell(请参阅 MySQL Shell 8.4.0)使用 AdminAPI(请参阅 第 6.1 节,“使用 MySQL AdminAPI”)触发,该 API 包含在 MySQL Shell 中。您还可以在主集群仍然可用的情况下执行从主集群到副本集群的受控切换,例如,如果需要对主集群进行配置更改或维护。MySQL Router(请参阅 MySQL Router 8.4)在 InnoDB ClusterSet 部署中自动将客户端应用程序路由到正确的集群。

InnoDB ClusterSet 部署中的副本集群在其保持为被动副本时不能与主集群分离,因为它不接受写入。应用程序可以读取它,尽管应该预料到异步复制的典型复制延迟量,因此数据可能尚不完整。副本集群的最小大小是一个成员服务器实例,但为了实现容错,建议至少使用三个成员。如果需要更多成员,例如,因为副本集群已通过切换或故障转移成为主集群,您可以随时通过 MySQL Shell 使用 AdminAPI 添加更多实例。InnoDB ClusterSet 部署中可以具有的副本集群数量没有限制。

下图中的示例 InnoDB ClusterSet 部署包含罗马数据中心中的主 InnoDB 集群,以及里斯本和布鲁塞尔数据中心中的副本集群。主集群及其副本集群分别包含三个成员服务器实例:一个主实例和两个辅助实例。

图 8.1 InnoDB ClusterSet 概述

Three MySQL InnoDB Clusters are formed from groups of three MySQL servers. Two clusters are replica clusters and one is the primary cluster. Asynchronous replication channels connect the primary cluster to each of the replica clusters. MySQL Router connects client applications to the primary cluster for write traffic, and to either the primary cluster or a replica cluster for read traffic.

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

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

重要的是要知道,InnoDB ClusterSet 优先考虑可用性而不是数据一致性,以便最大程度地提高灾难容错能力。每个单独的 InnoDB 集群内的一致性由底层的 组复制 技术保证。但是,正常的复制延迟或网络分区可能意味着在主集群遇到问题时,部分或全部副本集群与主集群不完全一致。在这些情况下,如果您触发紧急故障转移,则任何未复制或发散的事务都有丢失的风险,并且只能手动恢复和协调(如果可以访问它们)。不能保证在紧急故障转移的情况下数据将被保留。

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

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