我不擔心腦裂，因為兩台伺服器之間的連接是牢固的（而且因為我沒有第三台機器）
我想要一些具有自動故障轉移功能的 MariaDB 複製，這樣即使一個資料庫掛掉了，它也能繼續工作。我見過 MaxScale，但由於我只有兩台機器，它必須與其中一台伺服器在同一台機器上運行，如果該伺服器死機，那麼什麼都不起作用。 AFAIK，MariaDB Galera 叢集將拒絕允許我僅在兩個叢集上運行並進行自動故障轉移（需要法定人數）。但是，我也許可以在另一台電腦上運行仲裁程序，甚至可以在其上運行另一個資料庫，但速度會很慢。
此外，後端是 PHP - 我願意更改 mysqli 設定等，但我不知道是否需要更改或需要更改什麼。
編輯：我願意放棄自動故障轉移，但我想要的行為如下：
如果我連接到伺服器A，它會連接到資料庫A（主）並正常讀取/寫入。
如果我連接到 Serer B，它會連接到資料庫 B（只讀從屬）並且讀取取得很好。如果必須寫入，它可以寫入，但會將它們推送到資料庫 A。
在兩台伺服器上使用 MaxScale 或類似的東西是否可以實現這一點？
答案1
你有兩個節點。不要使用任何類型的主-主，它非常容易在兩個節點上出現腦裂（幾乎肯定最終會發生）。
不能指望這種有狀態應用程式能夠很好地自行處理兩節點叢集部署 - 需要操作員幹預或 CRM 才能使叢集在發生故障時保持穩健 - 這就是它的原因聚集在第一位。
您有一個兩節點叢集。您絕對應該擔心裂腦，因為該架構很容易出現裂腦情況。僅僅因為節點間網路連結現在很牢固，並不意味著它會永遠如此，這是兩節點叢集中最大的風險組成部分之一。失去該連結將立即導致集群分裂，除非擊劍或者法定人數節點之間建立。這是兩節點集群中最重要的考慮因素之一，因為防護將裂腦情況的可能性從高降低到接近零。
我建議使用 Pacemaker/Corosync 來處理此問題。它是一個複雜的堆疊，但提供了在兩個節點中生成生產級叢集所需的機制。我還建議一次只使用一個主實例，而不是多主實例，即使是在這樣的叢集管理器的強制執行下也是如此。
有一個很好的 HA MariaDB 指南可以作為起點。它不包括圍欄的使用。如果您無法完成防護，Corosync 還可以使用運行投票守護程序的小型仲裁器節點來提供仲裁的整體實現，而無需應用程式開銷成本（請參閱有關 Corosync qdevice 的資訊）。
它位於訂閱牆後面，但它是有關配置主動-被動 MySQL 叢集、一次在一個節點上運行以及在節點之間複製區塊儲存的端到端指南
Pacemaker 高級資源類型涵蓋了有關如何優雅地編排故障轉移的大部分問題，能夠將資源分組到線性依賴鏈中，並表達多狀態領導者選舉語義以跨節點運行應用程式的多個實例。可以在這裡找到。
捆綁包是透過 Docker 和 RKT 等容器運行時在 Pacemaker 中實現應用程式隔離的方法。這開闢了另一條防護途徑，因為這些捆綁包在叢集中表現為 Pacemaker 節點本身 - 因此它們可以由叢集獨立於其他應用程式進行「防護」。可以在這裡找到。
答案2
我以相同的理念運行各種資料庫（Mongo、Elasticsearch、SQL Server 等）「我不關心問題，我只能運行兩個節點」。
這是一個充滿傷害的世界。
如果你運行主從，沒問題。但也會有頭痛的情況。
經過多年圍繞這個問題的討論，並處理因我堅持只使用兩個節點而產生的各種DevOps 難題（我堅持這樣做是因為我們的數據庫非常大，並且第三個節點的成本很高），我終於開始運行三個節點節點。
然後一切都變得更好了。
我從多年的舞蹈經驗中學到的教訓是：有兩種選擇：
- 具有熱備用的單節點（例如主從）
- 三個節點
根據我的經驗，我永遠不會再次運行兩個節點的主動-主動（除非有一個神奇的部件可以完全防止腦裂，我已經見過，而且非常醜陋）。
五年來在各種堆疊上運行多個 0.5-1.5TB 資料庫。
答案3
一種選擇是使用 keepalived 運行非同步主主複製，以對浮動 IP 進行故障轉移。這不是很好，但它可以涵蓋徹底的伺服器故障場景。
您是否有 ILO 或其他一些方法可以使一台機器強制關閉另一台機器（STONITH）？這確實需要防止部分故障，例如機器崩潰但不是完全崩潰，因此它仍然足夠活躍以響應心跳資料包，但否則無法工作。這可能會導致故障轉移在應該發生的時候沒有發生。