MySQL Cluster 7.3 如何实现 99,999% 的可用性？ CAP定理的对立面答案

【问题标题】：How can MySQL Cluster 7.3 achieve 99,999% Availability? Antithesis to CAP TheoremMySQL Cluster 7.3 如何实现 99,999% 的可用性？ CAP定理的对立面
【发布时间】：2013-07-01 01:56:01
【问题描述】：

根据"Guide to Scaling Web Databases with MySQL Cluster"，MySQL Cluster 7.3 在使用同步更新复制时可以实现 99,999% 的可用性。这将与CAP Theorem 形成对立面，因为它表明完美的可用性（99,999% 可以看作是这样，不是吗？）并且在分布式系统中无法实现一致性。

如果负责副本的数据节点不可访问，集群将如何对更新做出反应？对于同步更新复制，它必须阻塞，这会影响可用性。

指南指出：

数据节点内的数据同步复制到所有节点节点组内。如果一个数据节点发生故障，那么总是有至少一个存储相同信息的其他数据节点。

如果发生数据节点故障，MySQL 服务器或应用程序节点可以使用节点组中的任何其他数据节点来执行交易。应用程序只是重试事务和剩余的数据节点将成功满足请求。

但是如果一个节点组由两个节点和一个崩溃组成（例如here），这将如何工作？据我所知，没有节点可以将更新复制到使用同步更新复制时会导致更新失败的内容？！复制是否只是在不存在要写入副本的节点时暂停？

【问题讨论】：

标签： mysql high-availability consistency distributed-database

【解决方案1】：

在您的示例问题中，问题不包括 partition。分区意味着一半的数据会留在一个节点，另一半会留在另一个节点（不需要是 50% 的一半，但需要将数据分成几个节点）。

在您的示例问题中，如果其中一个节点崩溃，另一个节点仍在工作；因此您有 可用性。而且因为其中一个节点是另一个节点的副本，所以您应该没有一致性的问题。

仅仅因为更新失败，并不代表数据不一致。如果您尝试访问集群中的数据，您将获得一致的数据，因为您无法从死节点检索不一致的数据。

也就是说，只有查询集群，重试的数据不一致，才会有不一致的数据。

【讨论】：

也许我们可以进行读取，但是如果我们每个节点组只剩下一个节点并且副本数定义为两个，则剩余节点不能接受写入，因为它无法更新第二个复制品？还是我这里有什么问题？
@NorRen 否，如果所有节点都是 master，它们将接受更新请求并与其余节点同步。如果一个节点死了，当然就不能更新了。如果一个节点死了，系统将继续运行，这就是为什么你有多个节点而不是一个； 如果您不希望系统停止接受更新请求，您应该拥有多个主服务器，而不是主从架构。这个或一个从节点被提升为新的主节点。

【解决方案2】：

在主-主复制中，如果主机之间的连接断开，那么如果您尝试更改任何主机的任何数据库中的数据，那么肯定要实现这种可用性，一致性就会被破坏。因为现在主机没有同步，所以数据不一致。请看以下案例：

案例 1：得到 A 和 C 而不是 P

例如，如果我不复制数据库，那么整个数据库都在单个主机中。所以在这里我们得到的是一致性和可用性，而不是分区容差。

案例 2：得到 C 和 P 而不是 A

例如，如果我复制一个数据库（master-master）并将每个数据库保存在两个主机中。 P1 部分在主机 H1 中，P2 部分在主机 H2 中。现在为了获得分区容差，我可以切断 H1 和 H2 的连接。现在为了保持一致性，我不允许任何人更改 P1 和 P2 中的任何一个。最终我们将失去可用性。

案例 3：得到 A 和 P 而不是 C

例如，如果我复制一个数据库（master-master）并将每个数据库保存在两个主机中。 P1 部分在主机 H1 中，P2 部分在主机 H2 中。现在为了获得分区容差，我可以切断 H1 和 H2 的连接。现在为了获得可用性，我将允许任何人更改 P1 和 P2 中的任何一个。最终我们会失去一致性。

【讨论】：