MySQL 故障轉移 - 主到主複製
我的公司正在嘗試實施 MySQL 故障轉移機制，以在我們的 Web 服務層實現更高的可用性——我們將 SaaS 解決方案商業化。為此，我們有一些分散在不同地理位置的低端虛擬機，每個都包含一個帶有多個數據庫的 MySQL 5.5 伺服器，暫時只是從生產伺服器進行從屬複製 - 到目前為止的目標只是檢查MySQL 複製的延遲和一般彈性。
然而，計劃是在兩個不同位置的兩台伺服器之間添加一個主-主複製環境，這兩個實例將處理所有數據庫寫入。這個想法不一定意味著並發。相反，目的是讓單個實例處理寫入，並在停機情況下使用 DNS 故障轉移服務將請求定向到輔助伺服器。主伺服器恢復上線後，此時在輔伺服器中生成的 b-log 將被複製回來，DNS Failover 將請求恢復到第一個請求。
我不是一個有經驗的管理員，所以我問你自己的想法和經驗。這種構想有多麼錯誤？有什麼明顯的問題？有更好的選擇嗎？扑街！
謝謝！
我正在考慮完全按照您的描述使用 Amazon 的 Route 53 DNS 故障轉移。所以想法是將2個數據庫設置為master-master
db1.domain.com db2.domain.com
然後設置 Route53“故障轉移”
db.domain.com -> 主要是 db1.domain.com => 埠 3306 上基於 TCP 的健康檢查 -> 次要是 db2.domain.com => 埠 3306 上基於 TCP 的健康檢查
我還沒有達到這一點，但這是我的計劃
您可能知道，master-master 設置的問題是衝突。如果（例如）在不同的 master 上同時刪除和更新同一行，這將導致複製中斷。您提到您只想為故障轉移執行此操作，但這種風險在故障轉移期間仍然存在。例如，您要升級 master1。你切換DNS。新的寫入被定向到 master2。一個長事務在 master1 上完成，它被複製到 master2，並且發生了衝突。
如果您用於自動故障轉移的任何工具在幾秒鐘內無法連接到 master1，但 master1 仍在執行，也會發生這種情況。它切換。新寫入轉到 master2。一些客戶端仍然連接到master1，他們寫入，發生衝突。
當然，重用相同的連接（例如通過代理）會增加這種風險——但我仍然認為這是一個很好的優化。
其他可能的災難原因包括人為錯誤。您對數據手動執行某些操作，但您在 master2 上錯誤地執行此操作，等等，出現了衝突。
這應該回答您的問題“可能出了什麼問題”，但還有一點更重要：有一天您可能需要擴大規模，而不僅僅是閱讀。在大多數情況下，由於衝突，不能簡單地分發寫入，甚至可能再添加一個主控。
我不是說師父不好。我用它。但我建議您評估 2 個替代方案，以防您沒有：
- 集群（如 Galera）。衝突不會持續存在：如果不同伺服器上的 2 個同時查詢產生衝突，其中一個將失敗。好吧，實際上有邊緣情況。但我在極端情況下看到的最糟糕的事情是一個單節點崩潰。你還有 2 個。當然，集群也有很多缺點，比如昂貴的寫入和 DBA 在 SST 發生時自殺。所以我不是建議這樣做，我只是指出我會考慮這個選項。
- 具有 1 個主控和 N 個從屬的更傳統的環境，外加 Orchestrator 或類似軟體。如果 Orchestrator 無法連接到主伺服器，它會檢查從伺服器是否可以。如果他們不能，它會選擇其中之一進行故障轉移。它考慮了幾個方面，例如伺服器版本和二進制日誌格式。當然還有複製滯後——但它不是依賴 Seconds_behind_master（它不可靠且粒度低得離譜），而是檢查最後一個複制的事務。此外，它使用自己的 GTID 實現——這對你很有用，因為 5.5 沒有它，對很多其他人來說，因為它是一個軟體中最容易出錯的功能（更不用說它的錯誤了） .
如果您最終決定使用 master-master，我建議您在正常工作時間以非瘋狂流量定期測試故障轉移。所以當情況不好時，你會避免糟糕的意外。
希望這可以幫助。