Mysql高一致高可用方案
一句話總結:使用官方Mysql Innodb Cluster叢集方案實現Mysql冗餘備份,無單點故障的高可用性。
專案背景:
1、對資料可用性要求高,要求多節點冗餘備份,Mysql單點故障後可以切換到其他節點
2、對資料準確性要求高,對Mysql寫資料時,需要強一致性備份,不能是非同步的備份
3、併發請求低
業內方案:
方案 | 優點 | 缺點 |
主備或一主多備,預設為非同步複製,可安裝外掛半同步複製 | 官方方案,可進行讀寫分離,配置較簡單 | 1、寫節點單點故障 2、預設非同步備份,非強一致性 3、將從庫提升為主庫需要應用層實現 |
雙主 + keepalive + 虛IP | 雙主可同時寫 | 1、引入了keepalive元件 2、雙主同時寫存在較多衝突場景 |
MariaDB Gelera Cluster | 支援多寫和高可用性,同步複製備份,每個節點保留全部資料 | 1、全同步寫,寫效能較低 2、不支援鎖的SQL如lock/unlock等 3、不支援XA事務 |
Mysql NDB Cluster | 官方方案,支援分片即分散式儲存,支援多寫,號稱可做到99.999%的可用性 | 1、架構複雜,部署也較複雜 2、管理節點的可靠性需額外再考慮 |
Mysql Fabric | 早起Oracle出的方案,支援分片和基於同步或半同步的複製備份 | 1、用的人較少,方案有點不成熟 2、需要修改程式碼,使用特定的mysql-connector |
業內在冗餘備份的基礎上,提高併發能力的設計思路有:
1、讀寫分離,單入口寫,多節點同時讀
2、寫併發提升:資料分片,即類似分庫,1~100的資料分佈在節點A,100~200的資料分佈在節點B,不同分片的資料如2和102可同時寫
3、寫併發提升:多主即多寫,大多數情況不同資料同時寫,當碰到同時操作同一資料如update同一條記錄,由額外的仲裁流程介入,Mysql多主模式的處理方式為先提交的事務寫成功,後提交的事務失敗丟擲異常,由應用層面處理看是丟棄或是讀取最新事務後重新發起事務
採用方案:
由於分片、多寫等複雜的方案架構複雜,都有一些限制,而專案還用到了Mysql的事務,XA事務,事務隔離,事務傳播,表鎖,行鎖等,固應根據專案需要選擇儘量簡單的方案,採用Mysql官方的Innodb Cluster方案:
Mysql Innodb Cluster方案其實是由Mysql幾個功能和外掛組成的:
1、Mysql Group Replication組複製
基於paxos協議的高一致性備份,寫節點掛掉後自動重新選主,支援單主模式和多主模式(這裡我們採用單主模式)。具體如下:
1)高一致性
基於原生複製及 paxos 協議的組複製技術,提供一致資料安全保證
2)高容錯性
多數派機制,只要不是超過一半節點掛掉就能工作,內建了叢集檢測、fail-tolarence、fail-over等機制
3)高擴充套件性
節點的新增和移除都是自動的,新節點加入後,會自動從其他節點上同步狀態,直到新節點和其他節點保持一致,如果某節點被移除了,其他節點自動更新組資訊,自動維護新的組資訊
4)高靈活性
有單主模式和多主模式,單主模式下,所有寫操作都在主上進行;多主模式下,所有 server 都可以同時處理寫操作
2、Mysql Router
Mysql Router更多是為應用層面服務的,假設應用層面如hibernate配置了資料庫url為具體某個寫節點,當該節點掛掉後,雖然組複製機制會自動重新選主,但應用層面就需要做額外處理如切換資料來源等。
而Mysql Router可以為應用層面遮蔽下面資料庫的變化,提供統一的操作入口。
3、Mysql shell
Mysql shell是作為Mysql Cluster的命令列管理工具。
引用:
https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html
https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html
https://dev.mysql.com/doc/mysql-router/8.0/en/mysql-router-innodb-cluster.html