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％的一半，但數據需要分成幾個節點）。

---

而且在你的榜樣的問題，如果節點崩潰的一個，另一個是仍在工作;因此你有可用性。並且因爲其中一個節點是其他的副本，所以您應該沒有問題，一致性。

僅僅因爲更新失敗，並不意味着數據不一致。如果您嘗試訪問集羣中的數據，您將擁有一致的數據，因爲您無法從死節點檢索不一致的數據。

換句話說，如果查詢集羣並且重試的數據不一致，則只有不一致的數據。