在我的德國供應商出現大量資料問題後，我現在被迫處理故障轉移場景。但有幾個問題我找不到真正的答案。所以我希望有人能在這裡幫助我。
我目前有 server1 在單獨的 docker 容器中運行兩個 MySQL 資料庫。這些現在應該複製到第二台伺服器上。如果 server1 故障，我可以透過 ClusterIP 相對快速地切換到 server2。
重要的是要知道：使用資料庫的軟體是一個體育比賽管理系統，它對資料庫進行大量寫入操作（未經測試，但總體上沒有寫入讀取操作）。
現在我的問題是：
- 哪種複製方法最適合？
- 據我了解，MASTER <-> MASTER 是最適合的。但我也在這裡一遍又一遍地讀到，問題可能會出現。
- 對於 MASTER <-> SLAVE，會出現從機只能讀取的問題。如果master失敗了怎麼辦？那麼從機是否會自動成為主機並且也可以寫入？
- 或者叢集是最好的解決方案嗎？目前我只有一個活動節點。未來可能會在美國添加另一個資料庫節點。但目前它還不存在。
我真的很感謝任何幫助，因為我需要一個快速工作的解決方案，而這個一般主題似乎非常龐大而且並不那麼容易。
答案1
你提出兩個問題。
MySQL 拓撲按順序（從好到最好）
- 主 -> 副本——可以實現“故障轉移”，但需要手動操作，因此需要時間。
- Primary <=> Primary——設定起來稍微複雜一些，同時提供對其他伺服器的「即時」使用。
- 至少 3 個伺服器的叢集。這進一步實現了故障轉移的自動化。請參閱「InnoDB 叢集」(MySQL 8) 或「Galera」（包含在 MariaDB 中）。
地理位置－請注意，即使是資料中心也可能發生故障。例如，佛羅裡達州有多少地區會因為一次颶風而停電？
請注意“裂腦”情況。在這種情況下，您只有兩台伺服器，兩台伺服器都運作良好，但網路已關閉。他們無法判斷，你也無法判斷情況如何。如果每個伺服器都認為自己是唯一活著的伺服器並繼續進行寫入，那麼最終會陷入混亂。因此，您必須假設整個系統已關閉。
底線—您至少需要 3 台實體上分開的伺服器。
代理人
仍然存在這樣的問題客戶了解資料庫系統的哪一部分是活動的（用於讀取和/或寫入）。當只有“讀取”很重要時，許多具有任意數量副本的拓撲就足夠了——並提供“無限”的擴展。 「寫入」才是真正的挑戰所在。
有幾種第 3 方產品擅長注意到一台伺服器已關閉並“做正確的事情”，重新路由到其他伺服器。研究他們。
編碼
當發生故障時，您的程式碼可能會出現某種錯誤。您必須檢查是否有錯誤，有些錯誤是無法自我修復的。大多數網路錯誤需要一段時間才能注意到。