轉載自 https://zhuanlan.zhihu.com/p/25960208
1. 概述
我們在考慮MySQL數據庫的高可用的架構時仗谆，主要要考慮如下幾方面：
- 如果數據庫發(fā)生了宕機或者意外中斷等故障业踏，能盡快恢復數據庫的可用性伏恐，盡可能的減少停機時間，保證業(yè)務不會因為數據庫的故障而中斷。
- 用作備份璧针、只讀副本等功能的非主節(jié)點的數據應該和主節(jié)點的數據實時或者最終保持一致。
- 當業(yè)務發(fā)生數據庫切換時渊啰，切換前后的數據庫內容應當一致探橱，不會因為數據缺失或者數據不一致而影響業(yè)務。
關于對高可用的分級在這里我們不做詳細的討論绘证，這里只討論常用高可用方案的優(yōu)缺點以及高可用方案的選型隧膏。
2. 高可用方案
2.1. 主從或主主半同步復制
使用雙節(jié)點數據庫，搭建單向或者雙向的半同步復制迈窟。在5.7以后的版本中私植，由于lossless replication、logical多線程復制等一些列新特性的引入车酣，使得MySQL原生半同步復制更加可靠曲稼。
常見架構如下：
通常會和proxy、keepalived等第三方軟件同時使用湖员，即可以用來監(jiān)控數據庫的健康贫悄，又可以執(zhí)行一系列管理命令。如果主庫發(fā)生故障娘摔，切換到備庫后仍然可以繼續(xù)使用數據庫窄坦。
優(yōu)點：
架構比較簡單，使用原生半同步復制作為數據同步的依據凳寺；
雙節(jié)點鸭津，沒有主機宕機后的選主問題，直接切換即可肠缨；
雙節(jié)點逆趋，需求資源少，部署簡單晒奕；
缺點：
完全依賴于半同步復制闻书，如果半同步復制退化為異步復制，數據一致性無法得到保證脑慧；
需要額外考慮haproxy魄眉、keepalived的高可用機制。
2.2. 半同步復制優(yōu)化
半同步復制機制是可靠的闷袒。如果半同步復制一直是生效的坑律，那么便可以認為數據是一致的。但是由于網絡波動等一些客觀原因霜运，導致半同步復制發(fā)生超時而切換為異步復制脾歇，那么這時便不能保證數據的一致性蒋腮。所以盡可能的保證半同步復制，便可提高數據的一致性藕各。
該方案同樣使用雙節(jié)點架構池摧，但是在原有半同復制的基礎上做了功能上的優(yōu)化，使半同步復制的機制變得更加可靠激况。
可參考的優(yōu)化方案如下：
2.2.1. 雙通道復制
半同步復制由于發(fā)生超時后作彤，復制斷開，當再次建立起復制時乌逐，同時建立兩條通道竭讳，其中一條半同步復制通道從當前位置開始復制，保證從機知道當前主機執(zhí)行的進度浙踢。另外一條異步復制通道開始追補從機落后的數據绢慢。當異步復制通道追趕到半同步復制的起始位置時，恢復半同步復制洛波。
2.2.2. binlog文件服務器
搭建兩條半同步復制通道胰舆，其中連接文件服務器的半同步通道正常情況下不啟用，當主從的半同步復制發(fā)生網絡問題退化后蹬挤，啟動與文件服務器的半同步復制通道缚窿。當主從半同步復制恢復后，關閉與文件服務器的半同步復制通道焰扳。
優(yōu)點：
雙節(jié)點倦零，需求資源少，部署簡單吨悍；
架構簡單扫茅，沒有選主的問題，直接切換即可;
相比于原生復制育瓜，優(yōu)化后的半同步復制更能保證數據的一致性诞帐。
缺點：
需要修改內核源碼或者使用mysql通信協議。需要對源碼有一定的了解爆雹，并能做一定程度的二次開發(fā)。
依舊依賴于半同步復制愕鼓，沒有從根本上解決數據一致性問題钙态。
2.3. 高可用架構優(yōu)化
將雙節(jié)點數據庫擴展到多節(jié)點數據庫，或者多節(jié)點數據庫集群菇晃〔岬梗可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群磺送。
由于半同步復制驻子，存在接收到一個從機的成功應答即認為半同步復制成功的特性灿意，所以多從半同步復制的可靠性要優(yōu)于單從半同步復制的可靠性。并且多節(jié)點同時宕機的幾率也要小于單節(jié)點宕機的幾率崇呵，所以多節(jié)點架構在一定程度上可以認為高可用性是好于雙節(jié)點架構缤剧。
但是由于數據庫數量較多，所以需要數據庫管理軟件來保證數據庫的可維護性域慷』脑可以選擇MMM、MHA或者各個版本的proxy等等犹褒。常見方案如下：
2.3.1. MHA+多節(jié)點集群
MHA Manager會定時探測集群中的master節(jié)點抵窒，當master出現故障時，它可以自動將最新數據的slave提升為新的master叠骑，然后將所有其他的slave重新指向新的master李皇，整個故障轉移過程對應用程序完全透明。
MHA Node運行在每臺MySQL服務器上宙枷，主要作用是切換時處理二進制日志掉房，確保切換盡量少丟數據。
MHA也可以擴展到如下的多節(jié)點集群：
優(yōu)點：
可以進行故障的自動檢測和轉移;
可擴展性較好朦拖，可以根據需要擴展MySQL的節(jié)點數量和結構;
相比于雙節(jié)點的MySQL復制圃阳，三節(jié)點/多節(jié)點的MySQL發(fā)生不可用的概率更低
缺點：
至少需要三節(jié)點，相對于雙節(jié)點需要更多的資源;
邏輯較為復雜璧帝，發(fā)生故障后排查問題捍岳，定位問題更加困難;
數據一致性仍然靠原生半同步復制保證，仍然存在數據不一致的風險;
可能因為網絡分區(qū)發(fā)生腦裂現象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式算法保證集群數據的一致性睬隶，使用zookeeper可以有效的保證proxy的高可用性锣夹，可以較好的避免網絡分區(qū)現象的產生。
優(yōu)點：
較好的保證了整個系統(tǒng)的高可用性苏潜，包括proxy银萍、MySQL;
擴展性較好，可以擴展為大規(guī)模集群;
缺點：
數據一致性仍然依賴于原生的mysql半同步復制;
引入zk恤左，整個系統(tǒng)的邏輯變得更加復雜;
2.4. 共享存儲
共享存儲實現了數據庫服務器和存儲設備的解耦贴唇，不同數據庫之間的數據同步不再依賴于MySQL的原生復制功能，而是通過磁盤數據同步的手段飞袋，來保證數據的一致性戳气。
2.4.1. SAN共享儲存
SAN的概念是允許存儲設備和處理器（服務器）之間建立直接的高速網絡（與LAN相比）連接，通過這種連接實現數據的集中式存儲巧鸭。常用架構如下：
使用共享存儲時瓶您，MySQL服務器能夠正常掛載文件系統(tǒng)并操作，如果主庫發(fā)生宕機，備庫可以掛載相同的文件系統(tǒng)呀袱，保證主庫和備庫使用相同的數據贸毕。
優(yōu)點：
兩節(jié)點即可，部署簡單夜赵，切換邏輯簡單明棍；
很好的保證數據的強一致性；
不會因為MySQL的邏輯錯誤發(fā)生數據不一致的情況油吭；
缺點：
需要考慮共享存儲的高可用击蹲；
價格昂貴；
2.4.2. DRBD磁盤復制
DRBD是一種基于軟件婉宰、基于網絡的塊復制存儲解決方案歌豺，主要用于對服務器之間的磁盤、分區(qū)心包、邏輯卷等進行數據鏡像类咧，當用戶將數據寫入本地磁盤時，還會將數據發(fā)送到網絡中另一臺主機的磁盤上蟹腾，這樣的本地主機(主節(jié)點)與遠程主機(備節(jié)點)的數據就可以保證實時同步痕惋。常用架構如下：
當本地主機出現問題，遠程主機上還保留著一份相同的數據娃殖，可以繼續(xù)使用值戳，保證了數據的安全。
DRBD是linux內核模塊實現的快級別的同步復制技術炉爆，可以與SAN達到相同的共享存儲效果堕虹。
優(yōu)點：
兩節(jié)點即可，部署簡單芬首，切換邏輯簡單赴捞；
相比于SAN儲存網絡，價格低廉郁稍；
保證數據的強一致性赦政；
缺點：
對io性能影響較大；
從庫不提供讀操作耀怜；
2.5. 分布式協議
分布式協議可以很好解決數據一致性問題恢着。比較常見的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗余數據财破，實現數據庫的高可用性和數據一致性然评。
優(yōu)點：
全部使用官方組件，不依賴于第三方軟件狈究；
可以實現數據的強一致性；
缺點：
國內使用的較少；
配置較復雜抖锥，需要使用NDB儲存引擎亿眠，與MySQL常規(guī)引擎存在一定差異；
至少三節(jié)點磅废；
2.5.2. Galera
基于Galera的MySQL高可用集群纳像， 是多主數據同步的MySQL集群解決方案，使用簡單拯勉，沒有單點故障竟趾，可用性高。常見架構如下：
優(yōu)點：
多主寫入宫峦，無延遲復制岔帽，能保證數據強一致性；
有成熟的社區(qū)导绷，有互聯網公司在大規(guī)模的使用犀勒；
自動故障轉移，自動添加妥曲、剔除節(jié)點贾费；
缺點：
需要為原生MySQL節(jié)點打wsrep補丁
只支持innodb儲存引擎
至少三節(jié)點；
Paxos 算法解決的問題是一個分布式系統(tǒng)如何就某個值（決議）達成一致檐盟。這個算法被認為是同類算法中最有效的褂萧。Paxos與MySQL相結合可以實現在分布式的MySQL數據的強一致性。常見架構如下：2.5.3. POAXS
優(yōu)點：
多主寫入葵萎，無延遲復制导犹，能保證數據強一致性；
有成熟理論基礎陌宿；
自動故障轉移锡足，自動添加、剔除節(jié)點壳坪；
缺點：
只支持innodb儲存引擎
至少三節(jié)點舶得；
3. 總結
隨著人們對數據一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數據一致性的問題爽蝴，如MySQL自身的優(yōu)化沐批、MySQL集群架構的優(yōu)化、Paxos蝎亚、Raft九孩、2PC算法的引入等等。
而使用分布式算法用來解決MySQL數據庫數據一致性的問題的方法发框，也越來越被人們所接受躺彬，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規(guī)模使用宪拥。
隨著官方MySQL Group Replication的GA仿野，使用分布式協議來解決數據一致性問題已經成為了主流的方向。期望越來越多優(yōu)秀的解決方案被提出她君，MySQL高可用問題可以被更好的解決脚作。
