ToB企服应用市场:ToB评测及商务社交产业平台

标题: MySQL InnoDB Cluster – how to manage a split-brain situation [打印本页]

作者: 盛世宏图 时间: 2024-8-13 10:15
标题: MySQL InnoDB Cluster – how to manage a split-brain situation
本文是翻译MySQL InnoDB Cluster – how to manage a split-brain situation[1]这篇文章，如有翻译不妥或不对的地方，敬请谅解与指正。请恭敬原创和翻译劳动成果，转载的时候请注明出处。谢谢！
每次我展示MySQL InnoDB Cluster时，在创建集群的演示中，很多人都不明白为什么当我集群中已有2个成员时，我的集群还不能容忍任何以障。究竟上，当您创建MySQL InnoDB集群时，只要您添加了第二个实例，您就可以看到状态信息：

"status": "OK_NO_TOLERANCE",
"statusText": "Cluster is NOT tolerant to any failures.",

复制代码

仲裁(Quorum)

[译者注释] 这里Quorum翻译成仲裁，直译是法定人数。个人认为翻译成仲裁更好一些。
这是为什么呢？这是因为，要成为网络主分区（网络主分区指包含服务的网络分区，在默认的单主模式中指具有主节点的网络分区）的一部分，您的网络分区必须达到大多数节点（法定人数）。在MySQL InnoDB集群（和很多其他集群解决方案一样）中，要达到法定人数，分区中的成员数量必须大于50%。
[译者注释]：这里所谓的网络主分区（primary partition），其实是指集群中的节点可能由于网络故障导致变成了2个或多个隔离区域。是一个网络拓扑概念。
因此，当我们已有2个节点时，如果两个服务器之间出现网络问题，集群将分裂为2个分区。每个分区将拥有总成员数量的 50%（2 个中的1个）。那么50% > 50% 吗？不！在MySQL InnoDB集群的情况下，没有一个网络分区会达到法定人数，也没有一个网络分区允许查询。这就是原因。
究竟上，第一台服务器会发现它再也无法与第二台服务器通信了……但为什么呢？是第二台服务器宕机了吗？是不是网络接口出了问题？我们不知道，所以我们无法决定。
让我们看一下这个由3名成员组成的集群 (3/3 = 100%)：

如果我们看一下cluster.status()下令的输出信息，我们可以看到，有3个节点时可以容忍一个节点出现故障：

"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",

复制代码

现在让我们想象一下，我们遇到一个网络问题，它会隔离其中一个成员/节点：

我们可以在cluster.status()下令的输出信息中看到节点丢失：只要一个分区仍然具有法定人数（2/3 = 66%，大于 50%），我们的集群就仍然能够提供交易服务。

"mysql6:3306": {
"address": "mysql6:3306",
"mode": "n/a",
"readReplicas": {},
"role": "HA",
"status": "(MISSING)"
}

复制代码

这里我想介绍一个非常重要的概念，因为这并不总是显而易见的。InnoDB Cluster 和 Group Replication 中的集群概念是差别的。实际上，InnoDB Cluster 依赖于DBA使用 MySQL Shell创建的元数据。这些元数据描述了集群的设置方式。Group Replication 以差别的方式对待集群。它以前次查抄时的状态以及现在的状态来对待集群……并更新该视图。这通常被称为世界观(view of the world)。因此，在上面的示例中，InnoDB 集群看到 3 个节点：2 个在线，1 个丢失。对于组复制，在短时间内，网络分区中节点处于UNREACHABLE状态，几秒钟后，在被多数人从组中逐出后（因此只有在仍有多数人的情况下），该节点不再是集群的一部分。组大小现在是 2/2（2/2 而不是 2/3）。此信息可以通过performance_schema.replication_group_members获取。

如果我们的网络问题更加严重，并将我们的集群分成 3 个，如下图所示，那么集群将处于“离线”状态，因为这 3 个分区均未达到法定多数，即 1/3 = 33% (

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)