MySQL Shell 9.0  /  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 9.0.0)触发,使用 AdminAPI(参见第 6.1 节,“使用 MySQL AdminAPI”),该 API 包含在 MySQL Shell 中。您还可以从主集群到副本集群执行受控切换,而主集群仍然可用,例如,如果需要对主集群进行配置更改或维护。MySQL Router(参见MySQL Router 9.0)会自动将客户端应用程序路由到 InnoDB ClusterSet 部署中的正确集群。

InnoDB ClusterSet 部署中的副本集群在保持为被动副本时不会偏离主集群,因为它不接受写入。它可以被应用程序读取,尽管应该预料到异步复制的典型复制延迟,因此数据可能尚未完整。副本集群的最小规模是一个单成员服务器实例,但建议至少有三个成员以确保容错能力。如果需要更多成员(例如,因为副本集群已通过切换或故障转移变为主集群),您可以随时通过使用 AdminAPI 的 MySQL Shell 添加更多实例。对 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 复制通道,当集群为副本时,它使用该通道从主服务器复制事务。底层 Group Replication 技术管理该通道,并确保复制始终在主集群的主服务器(作为发送方)和副本集群的主服务器(作为接收方)之间进行。如果为主集群或副本集群选举了新的主服务器,则 ClusterSet 复制通道会在它们之间自动重新建立。

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

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

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

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