是否有*應用程序*驅動的理由更喜歡多主拓撲而不是集群，反之亦然？

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可確保寫入實際上對讀取可見。