MySQL 作為核心資料中台,高可用(HA)是必答題。Master 掛掉時,如何將資料損失降至最低、秒級感知故障並自動切換,需從 Replication(複製)、Monitor(監控)、Failover(故障轉移) 三個維度建構體系。
預設異步模式下,Master 寫入 Binlog 即回覆成功,不等待 Slave 接收。Master 宕機瞬間,未傳遞的 Binlog 事件將永久遺失。
Semi-synchronous Replication:Master 提交事務後,等待至少一個支援半同步的 Slave 確認收到事件並寫入 Relay Log 才回覆。極大降低資料遺失機率,效能影響極小(Facebook 生產環境驗證)。MySQL 5.7+ 引入 Loss-Less Semi-Sync,進一步將遺失風險壓至理論最低。
同步多主架構,寫入需過半數節點確認(預設 3 節點),資料零遺失。代價是對 MySQL 核心代碼侵入性強、寫入延遲隨網路抖動增大。適合「資料絕不能丟、業務可接受稍高延遲」場景。
作業系統層面鏡像磁碟,MySQL 無感知。但 MHA 作者指出 Split-brain 風險、效能抖動等缺陷,現較少作為首選。
基於 VIP 漂移,檢測粒度較粗(秒級心跳),無法即時感知 MySQL 進程掛掉但 OS 存活的情況。
PING 檢測可用性。ChildrenChanged 事件。優勢:全叢集統一視圖、事件驅動即時感知、多服務協同編排。
挑戰:部署複雜度高(Docker 化可緩解)、切換後應用如何獲取新地址(配合 VIP/Proxy/動態配置中心解決)。
比較 SHOW SLAVE STATUS 中 Master_Log_File、Read_Master_Log_Pos,Binlog 索引值與 Position 均最大者晉升為新 Master。
UUID:GID 唯一標識每個事務。Slave 指向新 Master 時,直接用 MASTER_AUTO_POSITION=1 或手動定位 GTID,避免傳統檔名+位移的模糊匹配。
參考 Orchestrator 實現:Master 每 10 秒建立一個 UUID 寫入 View,Binlog 記錄該事件。故障時只需在兩個 Slave 的 Binlog 中定位到同一 UUID 所在 10 秒窗口,再做精細對比,極大縮小搜尋範圍。
CREATE EVENT meta.create_pseudo_gtid_view_event
ON SCHEDULE EVERY 10 SECOND
DO BEGIN
SET @pseudo_gtid := UUID();
SET @stmt := CONCAT('CREATE OR REPLACE VIEW meta.pseudo_gtid_view AS SELECT ''', @pseudo_gtid, ''' AS pseudo_gtid_unique_val FROM dual');
PREPARE st FROM @stmt; EXECUTE st; DEALLOCATE PREPARE st;
END;