MySQL Cluster 7.3如何实现99,999％的可用性？与CAP的对立理论

Question

根据"Guide to Scaling Web Databases with MySQL Cluster"，MySQL Cluster 7.3在使用同步更新复制时可以实现99,999％的可用性。 这将与CAP Theorem相反，因为它表明完美的可用性（99,999％可以被看作是这个，不是？），并且在分布式系统中一致性是不可行的。

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

该指南指出：

• 一个数据节点中的数据同步复制至该节点组内的所有节点 。如果一个数据节点失败，那么总是有至少一个其他数据节点存储相同的信息。
• 如果发生数据节点故障，MySQL服务器或应用程序可以使用节点组中的任何其他数据节点来执行事务处理 。应用程序只需重试该事务，其余数据节点将成功满足该请求。

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

Answer 1

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

---

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

仅仅因为更新失败，并不意味着数据不一致。如果您尝试访问集群中的数据，您将拥有一致的数据，因为您无法从死节点检索不一致的数据。

换句话说，如果查询集群并且重试的数据不一致，则只有不一致的数据。