mysql 高可用方案梳理
阿新 • • 發佈：2018-11-20
mysql 高可用方案梳理
叢集部署種類
同步叢集
- 結構：
data + sql + mgm節點 - 特點
- 記憶體級別的，對硬體要求較低，但是對記憶體要求較大。換算比例為：
1：1.1 - 資料同時放在幾臺伺服器上，冗餘較好；
- 速度一般
- 建表需要宣告為
engine=ndbcluster - 擴充套件性強
- 可以實現高可用性和負載均衡，實現對大型應用的支援
- 必須是特定的mysql版本，如：已經編譯好的max版本
- 配置和管理方便，不會丟失資料
- 記憶體級別的，對硬體要求較低，但是對記憶體要求較大。換算比例為：
非同步叢集
- 結構：
master + slave - 特點
- 主從資料庫非同步資料
- 資料放在幾臺伺服器上，冗餘一般
- 速度較快
- 擴充套件性差
- 無法實現高可用性和負載均衡（只能在程式級別實現讀寫分離，減輕對主資料庫的壓力）
- 配置和管理較差，可能會丟失資料
叢集部署方案
高可用方案
- 主從或主主半同步複製:需要額外考慮
haproxy、keepalived的高可用機制 - 半同步複製優化
- 高可用架構優化
- 共享儲存
- 分散式協議
常見實現方式
| 方案 | 描述 | 優點 | 缺點 |
|---|---|---|---|
LVS + Keepalived（最常用） | 存在腦裂問題，還無法做到準確判斷mysqld是否HANG的情況 |
||
DRBD + Heartbeat |
存在腦裂問題，且DRDB並不需要，增加會有其他問題 |
||
MySQL Proxy |
無法高可用，是一個寫分離 | ||
MySQL Cluster |
官方叢集的部署方案，通過使用NDB儲存引擎實時備份冗餘資料，實現資料庫的高可用性和資料一致性。 | 全部使用官方元件，不依賴於第三方軟體；可以實現資料的強一致性； | 國內使用較少；配置較複雜，需要使用NDB儲存引擎，與mysql常規引擎存在一定差異； |
MySQL MHA |
可解決腦裂問題，但需要IP多，管理麻煩、坑多 |
相關產品比較
| 名稱 | 描述 |
|---|---|
amoeba |
中介軟體早期產品。應用連線amoeba操作mysql，就像操作單個mysql一樣，後端還在使用jdbc driver |
cobar |
amoeba基礎上發展版本，顯著變化是將jdbc driver改為原生mysql通訊協議層。去掉jdbc規範，即不能支援oracle等資料庫 |
mycat |
cobar基礎上發展版本，顯著變化是將BIO改為NIO，併發量大幅提高；增加對Order By、Group By、limit等聚合功能的支援 |
建議
依據業務場景、資料量、訪問量、併發量、高可用要求等綜合權衡。
- 若是雙主複製，不做資料拆分，可考慮使用
MHA、Keepalived、heartbeat - 若是雙主複製，做資料拆分，可考慮使用
Cobar（阿里mysql中介軟體） - 若是雙主複製 +
Slave，做資料拆分，需要讀寫分離，可考慮使用Amoeba（mysql代理，增強mysql，類似產品有mycat）
實現方案
名詞解釋
| 名稱 | 解釋 |
|---|---|
| 腦裂問題 | 在高可用（HA）系統中，當聯絡2個節點的“心跳線”斷開時，本來為一整體、動作協調的HA系統，就分裂成為2個獨立的個體。由於相互失去了聯絡，都以為是對方出了故障。 |