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