一、背景
需求：客戶要實現Mysql8.0+高可用，出現故障時，需要實現自動切換。
分析：實現切換有兩種方式，一種數據庫自動切換，一種代碼實現。
本著麻煩別人，別麻煩自己的原則，得給客戶的DBA派活兒了。
實現MySQL數據庫集群自動切換，核心目標是高可用性（High Availability, HA），即在主節點故障時，系統能自動、快速、安全地將服務切換到備用節點，最大限度減少停機時間。
二、方案收集
2.1. 方案一：主從復制
基于主從復制 + 高可用中間件/工具 (最主流、靈活)
架構:?
1個主節點（Master）: 負責處理所有讀寫請求。
1個或多個從節點（Slave）: 通過MySQL原?異步/半同步復制從主節點同步數據，通常配置為只讀。
?可?管理器:
Keepalived + VRRP: 提供?個虛擬IP（VIP）。Keepalived監控主節點健康狀態，若主故障，通過VRRP協議將VIP漂移到選定的從節點（需配合腳本提升該從為主）。
MHA (Master High Availability): 專為MySQL設計的成熟?具。Manager節點監控所有節點，主故障時?動選擇最新數據的從節點，將其提升為新主，并嘗試讓其他從庫指向新主。?持故障轉移、主節點切換等。（不維護啦，不做推薦）
ProxySQL / MaxScale (MariaDB) / HAProxy: 智能代理 層。應?連接代理，代理將寫請求轉發給主節點，讀請求 可轉發給從節點。代理持續監控后端節點健康狀態。主節 點故障時，代理?動將寫流量切換到新的主節點（通常需要配合 pt-heartbeat 或代理內置機制檢測延遲和復制狀態）。
【?動切換流程:】
1. 監控組件持續檢測主節點健康（?絡可達性、MySQL進程狀 態、復制狀態、?定義腳本如 SELECT 1 ）。
2. 檢測到主節點故障（超時?響應、服務宕機、復制嚴重延遲 等）。
3. ?可?管理器觸發故障轉移流程：確認主節點確實不可?（防?誤判）。
選擇?個最合適的從節點（通常是數據最接近主節點、復 制延遲最?的那個）。
提升該從節點為新的主節點（執? STOP SLAVE; RESETSLAVE ALL; 或類似操作，確保其可寫）。
如果使?VIP，則讓VIP漂移到新主節點。
如果使?代理，則更新代理配置，將寫請求指向新主。
（可選）讓其他從節點開始從新主節點復制數據。
4. 應?通過VIP或代理重新連接到新的主節點，恢復服務。
【優點】 技術成熟、靈活（可?由選擇組件）、成本相對較低（開源軟件為主）、?持讀寫分離。
缺點: 配置和管理相對復雜；異步復制存在數據丟失?險（除??半同步）；腦裂?險需妥善處理（如使?第三?仲裁）；代理層本?需要?可?（可?雙活代理+Keepalived VIP）。
適?場景: 對成本敏感、需要靈活配置、可接受?定配置復雜度的場景。是當前最?泛采?的?案。
2.2. 方案二：MGR
MySQL Group Replication (MGR) - MySQL官??案
架構:??少3個節點（推薦單主模式）
基于Paxos分布式?致性協議實現數據同步（多數派確認）。
內置組成員管理、故障檢測和?動主節點選舉。
單主模式：只有?個節點可寫（主節點），其他節點只讀（但具備完整數據）。
多主模式：所有節點均可讀寫（但沖突檢測和性能開銷?，?產環境慎?）。
【?動切換流程:】
1. 組內節點通過組通信系統持續通信。
2. 如果主節點故障或?絡分區導致失聯。
3. 剩余存活節點（需構成多數派）會?動檢測到主節點缺失。
4. 組內?動發起選舉，根據預設規則（如 group_replication_member_weight ）從存活的、數據?致的節 點中選出新的主節點。
5. 選舉過程快速（通常秒級）。?旦新主當選，組內狀態更新。
6. 應?需要感知新的主節點地址（通常需配合連接器如MySQL Router）。
【優點】原?集成于MySQL（>=5.7.17），?需額外中間件（除Router外）；內置強?致性保證（?級沖突檢測）；?動故障檢測與選舉； 避免腦裂（需多數派存活）；?持多節點寫?（多主模式）。
【缺點】性能開銷?異步復制?（需要多數派確認寫操作）；對?絡延 遲和穩定性要求極?；配置和管理有特定要求；腦裂后恢復可能復 雜；單主模式下讀擴展性不如主從+代理。
【適?場景】?對強?致性要求?、愿意接受?定性能開銷、希望使?官
?原??案、?絡環境良好的場景。是未來發展的重點?向。
2.3. 方案三：PXC/Galera Cluster
Percona XtraDB Cluster (PXC) / Galera Cluster
架構:
- ?少3個節點。
- 基于Galera庫實現的同步多主集群。
- 所有節點均可讀寫，數據寫?在提交前必須在集群內同步到其
- 他節點（通過Certification-Based Replication）。
- 使?基于組通信的 gcomm 協議進?節點間通信。
【?動切換流程:】
嚴格來說，PXC/Galera沒有傳統意義上的“主從切換”，因為它 是多主的。
如果某個節點故障，只要集群多數派（Quorum）存活（通常 N/2+1），集群就能繼續提供服務（讀寫在存活節點上進?）。
故障節點恢復后會從Donor節點?動進?SST（State Snapshot Transfer）或IST（Incremental State Transfer）同步數據重新加 ?集群。
【優點】真正的多主讀寫；強?致性；?可?性（節點故障對服務影響?，只要滿?Quorum）；?動成員管理和故障恢復；數據?乎?丟 失?險。
【缺點】?寫性能受限于最慢節點和?絡（同步復制開銷）；寫沖突可能導致回滾；需要較?的 wsrep_slave_threads ；SST過程可能影響Donor性能；對?絡要求極?；DDL操作需要特別??。
【適?場景】需要真正的多主寫?、對強?致性和?可?性要求極?、
能接受同步復制帶來的潛在性能瓶頸的場景。
2.4. 方案四：云數據庫
云數據庫?可?服務 (省?之選)架構:
直接使?阿?云RDS、AWS RDS、Azure Database for MySQL、騰訊云CDB等提供的托管MySQL服務。
云廠商在其底層實現了?可??案（通常是主從復制+類似Keepalived/MHA的?動故障轉移，或基于共享存儲如阿?云三節點企業版）
【?動切換流程:】
完全由云平臺管理。主節點故障時，云平臺?動檢測并觸發故障轉移，提升備節點為主節點。
切換過程對應?透明（通常通過DNS或Endpoint?動重定向）。
優點: 開箱即?，運維復雜度極低；云?商負責底層維護、監控、備份等；通常有SLA保障。
【缺點】成本通常?于?建；靈活性受限于云平臺提供的功能和配置選項；
可能存在?商鎖定?險。
【適?場景】希望最?程度減少數據庫運維負擔、預算充?、對云平臺 信任的場景。
三、決策
3.1方案比較
到底應該使用哪種方案呢？
云方案首先排除，客戶是自建服務。
那就對比方案一和方案二：
【提問】通過MySQL原生異步/半同步復制從主節點同步數據。和MGR方案的同步有什么區別呢？
【分析】
3.1.1 原生異步復制 (Async Replication)
特點：
- 數據可能丟失：Master 提交后即返回，Binlog 未同步到 Slave
- 延遲無上限：Slave 可能落后 Master 數小時
3.1.2 半同步復制 (Semi-Sync)
特點：
防丟數據：確保事務 Binlog 到達至少一個 Slave
不防延遲：Slave 可能未應用日志（僅保證收到）
主宕機仍丟數據：若 ACK 后 Slave 未應用日志
3.1.3 MGR
特點：
強一致性：事務提交需多數節點認證
零數據丟失：返回成功 = 數據在多數節點持久化
自動沖突解決：行級沖突檢測 (certification)
3.1.4?決策
搭建主從節點方式是局域網，局域網一般網絡延遲小于5ms。（當然這里需要驗證和測試）
四、安裝?
最終采用組復制+Router，請參考下面官方文檔：
Mysql Group?Replication 官網安裝步驟
Mysql Router 插件 官網安裝步驟
等等……
我既然選擇了MGR+Router，為啥不選擇InnoDB Cluster呢？
五、Mysql官方方案比較
上面提到的MHA已經在不維護了，那還得看其他的解決方案，這邊整理了官方以下方案：
- 主從半同步復制、
- InnoDB ReplicaSet、
- 組復制（MGR）、
- InnoDB Cluster、
- InnoDB ClusterSet
| 解決方案 | 底層技術 | 數據一致性 | 故障切換時間 | 容災級別 | 適用規模 | 運維復雜度 |
|---|
| 主從半同步復制 | 半同步復制 | 最終一致 | 30~60秒 | 節點級 | <1TB | ?? |
| InnoDB ReplicaSet | 異步復制+管理框架 | 最終一致 | 手動切換 | 節點級 | <5TB | ? |
| 組復制（MGR） | Paxos協議多節點同步 | 強一致（RPO=0） | <10秒 | 節點級 | <10TB | ??? |
| InnoDB Cluster | MGR+Router+Shell | 強一致（RPO=0） | <10秒 | 節點級 | 任意規模 | ?? |
| InnoDB ClusterSet | 多Cluster+異步復制 | 最終一致 | 分鐘級 | 地域級 | 超大規模 | ???? |
5.1. 主從半同步復制
（Semi-Synchronous Replication）
-
原理：主庫提交事務前需至少一個從庫確認接收Binlog，超時自動降級為異步復制
-
優勢：
? 數據丟失風險低于異步復制（如支付流水日志）
? 成本低（2節點即可部署）
-
局限：
? 切換時可能丟失超時窗口內的數據（默認10秒）
? 需配合Keepalived等工具實現VIP漂移
-
典型場景：
-
電商訂單查詢系統（讀多寫少）
-
制造業MES實時數據采集2
5.2. InnoDB ReplicaSet
-
原理：基于異步復制的自動化管理套件（MySQL Shell + Router），簡化主從配置9
-
優勢：
??分鐘級部署（自動配置復制賬號、GTID）
? 支持Router自動讀寫分離
-
局限：
??無自動故障切換（需手動提升主節點）
? 數據一致性弱（依賴異步復制）
-
典型場景：
-
中小型企業內部管理系統（OA、CRM）
-
開發測試環境高可用模擬
5.3. 組復制
（MGR, MySQL Group Replication）
-
原理：基于Paxos協議的多節點共識，事務需多數節點（N/2+1）認證后提交410
-
優勢：
??強一致性（金融級數據安全，如賬戶余額）
? 自動選主與節點自愈（無需外部工具）
-
局限：
? 僅支持InnoDB表且必須含主鍵58
? 網絡延遲>50ms時性能驟降
-
典型場景：
-
支付核心交易系統（RPO=0要求）
-
政務數據共享平臺（多部門數據強同步）
5.4. InnoDB Cluster
-
原理：整合MGR + MySQL Router（流量代理） + MySQL Shell（管理）
-
優勢：
??圖形化運維（一鍵擴縮容、故障修復）
? 讀寫分離自動路由（Router隱藏后端拓撲）
-
局限：
? 綁定MySQL官方生態（版本需嚴格兼容）
? Router需單獨部署高可用
-
典型場景：
-
云數據庫服務（如AWS RDS高可用版）
-
大型ERP系統（多模塊數據強一致）
5.5. InnoDB ClusterSet
-
原理：多個InnoDB Cluster通過異步復制組成跨地域集群，主Cluster故障時備用Cluster接管9
-
優勢：
??地域級容災（如機房級故障切換）
? 備用Cluster可提供只讀服務
-
局限：
? 跨集群切換需手動觸發
? 備用集群數據延遲（依賴異步復制）
-
典型場景：
-
跨國電商全球業務（多活地域部署）
-
金融行業兩地三中心容災架構
?如果對你有幫助，點個收藏?，點個贊
??再去官方盤文檔唄……
--------------------------------------------結束--------------------------------------------
擴展閱讀
![[實戰] 用1 PPS 馴服本地恒溫晶振（OCXO/TCXO）](http://pic.xiahunao.cn/[實戰] 用1 PPS 馴服本地恒溫晶振（OCXO/TCXO）)
)
)
【標題字體過小】問題根源與解決方案)
——CRUD進階與數據庫約束：構建健壯數據系統的基石)
