根据《使用 MySQL Cluster 扩展 Web 数据库指南》，MySQL Cluster 7.3 在使用同步更新复制的同时可以实现 99,999% 的可用性。这将与CAP 定理相反，因为它指出完美的可用性（99,999% 可以看作是这样，不是吗？）和一致性在分布式系统中是无法实现的。
如果负责副本的数据节点不可访问，集群将如何对更新做出反应？对于同步更新复制，它必须阻塞，这会影响可用性。
该指南指出：
- 数据节点内的数据同步复制到节点组内的所有节点。如果一个数据节点发生故障，那么总会有至少一个其他数据节点存储相同的信息。
- 在数据节点发生故障的情况下，MySQL 服务器或应用程序节点可以使用节点组中的任何其他数据节点来执行事务。应用程序只需重试事务，其余数据节点将成功满足请求。
但是，如果一个节点组由两个节点和一个崩溃组成（这里的示例），这将如何工作？据我所知，没有节点可以将更新复制到使用同步更新复制时会导致更新失败的内容？！复制是否只是在不存在要写入副本的节点时暂停？
在主-主复制中，如果主机之间的连接断开，那么如果您尝试更改任何主机的任何数据库中的数据，那么肯定要实现这种可用性，一致性就会被破坏。因为现在主机没有同步，所以数据不一致。请看以下案例：
案例 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 中的任何一个。最终我们正在失去一致性。
在您的示例问题中，问题不包括partition。分区意味着一半的数据将保留在一个节点中，另一半保留在另一个节点中（不需要是 50% 的一半，但需要将数据拆分为多个节点）。
同样在您的示例问题中，如果其中一个节点崩溃，另一个节点仍在工作；因此你有可用性。而且因为其中一个节点是另一个节点的副本，所以一致性应该没有问题。
仅仅因为更新失败，并不意味着数据不一致。如果您尝试访问集群中的数据，您将获得一致的数据，因为您无法从死节点检索不一致的数据。
也就是说，只有查询集群，重试的数据不一致，才会有不一致的数据。