是否有*应用程序*驱动的理由更喜欢多主拓扑而不是集群，反之亦然？

Question

我有一个当前使用单个主节点的应用程序，我希望通过设置互惠的多主节点（仅两个具有适当设置的自动auto-increment-increment和auto-increment-offset的主节点）或集群来进行多主节点- 带大写字母-C。 该数据库当前是 MariaDB 10.3，因此集群将是 Galera。

我对多主数据库的理解是应用程序可能不需要任何更改：应用程序将连接到单个数据库（无论哪个数据库），任何需要获取任何锁的事务都将在本地进行，任何自动将生成必要的增量值，并且一旦发生COMMIT ，该引擎将完成提交，并且复制到另一个节点失败的可能性将非常低。

但是对于Clustering ， COMMIT实际上需要更新其他节点以确保成功，在COMMIT期间（而不是在某些INSERT/UPDATE/DELETE期间）失败的可能性要高得多，因此应用程序确实需要内置一些自动重试逻辑。

以上是否准确，还是我高估了集群部署中COMMIT失败的可能性，或者甚至低估了多主环境中COMMIT失败的可能性？

从我读过的内容来看，Galera Cluster 在处理节点离开重新加入集群和添加新节点方面似乎更优雅一些。 Galera Cluster 真的只是多主服务器，数据库引擎处理所有繁琐的设置和管理，还是两者之间有一些主要区别？

老实说，相对于看似“更容易”和“更安全”的迁移到 multi-primary，迁移到 Galera Cluster 不会成为一个令人头疼的问题。

Answer 1

“多主节点”是指每个 Galera 节点都会接受写入吗？ （在其他情况下，“multi-primary”有不同的含义——而且只有一个 Replica。）

需要注意的一件事是：“批判性阅读”。

例如，当用户发布内容并将其写入一个节点，然后该用户从另一个节点读取时，他希望他的帖子出现。 请参阅wsrep_sync_wait 。

（详细说明比尔的评论。）原始写入的COMMIT等待每个其他节点说“是的，我可以并且将存储该数据”，但其他节点上的读取可能不会立即“看到”该值。 在wsrep_sync_wait之前使用SELECT可确保写入实际上对读取可见。