在 Citymobil，我們使用 MySQL 資料庫作為主要的持久性資料儲存。 我們有多個用於各種服務和目的的資料庫叢集。

主站的持續可用性是整個系統及其各個部分效能的關鍵指標。 主伺服器故障時的自動叢集復原大大減少了事件回應時間和系統停機時間。 在本文中，我將研究基於 MySQL 叢集的高可用性 (HA) 設計 MySQL 編排器 和虛擬 IP 位址 (VIP)。

基於VIP的HA解決方案

首先我簡單介紹一下我們的資料儲存系統是什麼。

我們使用經典的複製方案，其中一個可寫入存取的主副本和多個唯讀副本。 叢集可以包含一個中間主節點 - 一個既是其他節點的副本又是主節點的節點。 客戶端透過 HAProxy 存取副本，從而實現均勻的負載分配和輕鬆擴展。 使用HAProxy是由於歷史原因，目前我們正在遷移到ProxySQL。

複製是基於半同步模式進行的 GTID。 這意味著至少有一個副本必須記錄事務才能被視為成功。 這種複製模式在主節點發生故障時提供了效能和資料安全之間的最佳平衡。 基本上所有變更都使用以下方式從主伺服器傳輸到副本 Row Based Replication (RBR)，但有些節點可能有 mixed binlog format.

編排器定期更新叢集拓撲的狀態，分析收到的訊息，如果出現問題，它可以啟動自動復原程式。 開發人員對程式本身負責，因為它可以透過不同的方式實現：基於 VIP、DNS、使用服務發現服務或自編寫的機制。

如果主節點發生故障，恢復主節點的簡單方法是使用浮動 VIP 位址。

在繼續操作之前，您需要了解有關此解決方案的資訊：

• VIP 是不與特定實體網路介面關聯的 IP 位址。 如果某個節點發生故障或在計劃維護期間，我們可以將 VIP 切換到另一個資源，從而最大限度地減少停機時間。
• 釋放和發布虛擬IP位址是一種廉價且快速的操作。
• 要使用 VIP，您需要透過 SSH 存取伺服器，或使用特殊實用程序，例如， keepalived.

讓我們看看嚮導可能出現的問題，並想像一下自動恢復機制應該如何運作。

與主站的網路連線已消失，或硬體層級出現問題，伺服器無法使用

1. 編排器更新叢集拓撲，每個副本報告主節點不可用。 協調器開始選擇適合新主角色的副本並開始恢復。
2. 我們正在嘗試從舊主人那裡刪除 VIP - 但沒有成功。
3. 副本切換到主伺服器的角色。 正在重建拓撲。
4. 新增帶有 VIP 的新網路介面。 由於無法刪除 VIP，我們開始在後台定期發送請求 免費ARP。 這種類型的請求/回應可讓您更新所連接交換器上的 IP 和 MAC 位址對應表，從而通知您我們的 VIP 已移動。 這將可能性降到最低 split brain 返回舊主人時。
5. 所有新連線都會立即重新導向到新主伺服器。 舊連線失敗，並且在應用程式層級重複呼叫資料庫。

伺服器以正常模式運行，DBMS 等級發生故障

該演算法與前面的情況類似：更新拓撲並啟動復原過程。 由於伺服器可用，我們成功釋放了舊master上的VIP，將其轉移到新master上，並發送了幾個ARP請求。 舊master的可能回歸不應影響重建的叢集和應用程式的運行。

其他問題

副本或中間主伺服器故障 不導致 自動化操作，需要人工介入。

虛擬網路介面始終是暫時新增的，即伺服器重新啟動後，不會自動分配 VIP。 每個資料庫實例預設以唯讀模式啟動，orchestrator會自動將新的master切換為寫入並嘗試安裝 read only 在老師傅身上。 這些行動旨在減少可能性 split brain.

恢復過程中可能會出現問題，除了標準監控工具之外，還應該透過協調器 UI 進行通知。 我們透過新增此功能擴展了 REST API (PR 目前正在審查中）。

HA解決方案的總體框圖如下所示。

選擇新主人

編排者夠聰明並嘗試選擇 最適合的複製品 根據以下標準作為新主人：

• 副本落後於主伺服器；
• MySQL版本的master和replica；
• 複製類型（RBR、SBR 或混合）；
• 位於相同或不同資料中心；
• 可用性 errant GTID — 在副本上執行但不在主伺服器上執行的交易；
• 也考慮了自訂選擇規則。

並非所有球桿都是大師的理想候選人。 例如，可以使用副本來備份數據，或者伺服器的硬體配置較弱。 協調者 支持 您可以使用手動規則自訂候選人選擇首選項（從最優先到忽略）。

回應和恢復時間

在發生事件時，最大限度地減少系統停機時間非常重要，因此讓我們考慮一下影響協調器建立和更新叢集拓撲的 MySQL 參數：

• slave_net_timeout — 在連線被識別為遺失並重新連線之前，副本會等待來自主伺服器的新資料或心跳訊號到達的秒數。 該值越低，副本可以越快確定與主伺服器的通訊已中斷。 我們將此值設為 5 秒。
• MASTER_CONNECT_RETRY — 重新連接嘗試之間的秒數。 如果出現網路問題，此參數的較低值將允許快速重新連線並阻止叢集復原過程啟動。 建議值為 1 秒。
• MASTER_RETRY_COUNT — 重新連線嘗試的最大次數。
• MASTER_HEARTBEAT_PERIOD — 主設備發送心跳訊號的時間間隔（以秒為單位）。 預設為值的一半 slave_net_timeout.

編排器選項：

• DelayMasterPromotionIfSQLThreadNotUpToDate - 如果相等 true，那麼在副本的 SQL 執行緒完成中繼日誌中所有未套用的交易之前，主角色不會套用於候選副本。 我們使用此選項來避免在所有候選副本落後時遺失事務。
• InstancePollSeconds — 建構和更新拓樸的頻率。
• RecoveryPollSeconds — 拓樸分析的頻率。 如果偵測到問題，則會啟動拓撲恢復。 這 常數，等於 1 秒。

每個叢集節點由協調器每隔一次輪詢一次 InstancePollSeconds 秒當偵測到問題時，強制叢集狀態 更新，然後最終決定進行恢復。 透過嘗試不同的資料庫和協調器參數，我們能夠將回應和復原時間縮短至 30 秒。

試驗台

我們開始測試 HA 計劃並開發本地 試驗台 並在測試和生產環境中進一步實施。 本機站基於 Docker 完全自動化，讓您可以嘗試編排器和網路的配置，將叢集從 2-3 台伺服器擴展到數十台，並在安全的環境中進行練習。

在練習過程中，我們選擇一種問題模擬方法：使用立即射擊大師 kill -9，軟終止進程並停止伺服器（docker-compose stop），使用模擬網路問題 iptables -j REJECT 或 iptables -j DROP。 我們期望得到以下結果：

• Orchestrator 將在 10 秒內偵測到 Master 的問題並更新拓樸；
• 復原過程將自動啟動：網路配置將發生變化，主伺服器的角色將轉移到副本伺服器，拓撲將重建；
• 新的主伺服器將變得可寫，即時副本在重建過程中不會遺失；
• 資料將開始寫入新的主伺服器並進行複製；
• 總恢復時間不會超過30秒。

如您所知，由於不同的硬體和網路配置、合成負載和實際負載的差異等，系統在測試和生產環境中的行為可能會有所不同。 因此，我們定期在真實條件下進行練習，檢查當網路連接遺失或各個部件效能下降時系統的行為方式。 未來，我們希望為這兩種環境建立完全相同的基礎設施並自動化其測試。

發現

主儲存系統節點的健康狀況是SRE和營運團隊的主要任務之一。 基於VIP的編排器和HA解決方案的實施使我們取得了以下成果：

• 可靠地檢測資料庫叢集的拓撲問題；
• 自動快速回應主站相關事件，減少系統停機時間。

然而，該解決方案有其限制和缺點：

• 將 HA 方案擴展到多個資料中心將需要在它們之間使用單一 L2 網路；
• 在為新master分配VIP之前，我們需要在舊master上釋放它。 該過程是連續的，這會增加恢復時間；
• 釋放 VIP 需要透過 SSH 存取伺服器，或呼叫遠端過程的任何其他方法。 由於伺服器或資料庫遇到導致復原過程的問題，我們無法確定 VIP 刪除是否會成功完成。 這可能會導致兩台伺服器出現具有相同虛擬IP位址的問題 split brain.

避免 split brain，你可以使用該方法 斯托尼斯 （“Shoot The Other Node In The Head”），這可以完全隔離或停用問題節點。 還有其他方法可以實現叢集高可用：VIP和DNS的組合、服務發現和代理服務、同步複製等方法，這些方法各有缺點和優點。

我談到了我們創建 MySQL 故障轉移叢集的方法。 它易於實施，並在當前條件下提供可接受的可靠性等級。 隨著整個系統、特別是基礎建設的發展，這種方法無疑會發展出來。

來源： www.habr.com