多圖文，詳細(xì)介紹mysql各個集群方案
集群的好處
- 高可用性：故障檢測及遷移，多節(jié)點(diǎn)備份。
- 可伸縮性：新增數(shù)據(jù)庫節(jié)點(diǎn)便利，方便擴(kuò)容。
- 負(fù)載均衡：切換某服務(wù)訪問某節(jié)點(diǎn)，分?jǐn)倖蝹€節(jié)點(diǎn)的數(shù)據(jù)庫壓力。
集群要考慮的風(fēng)險(xiǎn)
- 網(wǎng)絡(luò)分裂：群集還可能由于網(wǎng)絡(luò)故障而拆分為多個部分，每部分內(nèi)的節(jié)點(diǎn)相互連接，但各部分之間的節(jié)點(diǎn)失去連接。
- 腦裂：導(dǎo)致數(shù)據(jù)庫節(jié)點(diǎn)彼此獨(dú)立運(yùn)行的集群故障稱為“腦裂”。這種情況可能導(dǎo)致數(shù)據(jù)不一致，并且無法修復(fù)，例如當(dāng)兩個數(shù)據(jù)庫節(jié)點(diǎn)獨(dú)立更新同一表上的同一行時。
@[toc]
一，mysql原廠出品
1，MySQL Replication
mysql復(fù)制（MySQL Replication），是mysql自帶的功能。
原理簡介：
主從復(fù)制是通過重放binlog實(shí)現(xiàn)主庫數(shù)據(jù)的異步復(fù)制。即當(dāng)主庫執(zhí)行了一條sql命令，那么在從庫同樣的執(zhí)行一遍，從而達(dá)到主從復(fù)制的效果。在這個過程中，master對數(shù)據(jù)的寫操作記入二進(jìn)制日志文件中(binlog)，生成一個 log dump 線程，用來給從庫的 i/o線程傳binlog。而從庫的i/o線程去請求主庫的binlog，并將得到的binlog日志寫到中繼日志（relaylog）中，從庫的sql線程，會讀取relaylog文件中的日志，并解析成具體操作，通過主從的操作一致，而達(dá)到最終數(shù)據(jù)一致。
MySQL Replication一主多從的結(jié)構(gòu)，主要目的是實(shí)現(xiàn)數(shù)據(jù)的多點(diǎn)備份（沒有故障自動轉(zhuǎn)移和負(fù)載均衡）。相比于單個的mysql，一主多從下的優(yōu)勢如下：
- 如果讓后臺讀操作連接從數(shù)據(jù)庫，讓寫操作連接主數(shù)據(jù)庫，能起到讀寫分離的作用，這個時候多個從數(shù)據(jù)庫可以做負(fù)載均衡。
- 可以在某個從數(shù)據(jù)庫中暫時中斷復(fù)制進(jìn)程，來備份數(shù)據(jù)，從而不影響主數(shù)據(jù)的對外服務(wù)（如果在master上執(zhí)行backup，需要讓master處于readonly狀態(tài)，這也意味這所有的write請求需要阻塞）。
就各個集群方案來說，其優(yōu)勢為：
- 主從復(fù)制是mysql自帶的，無需借助第三方。
- 數(shù)據(jù)被刪除，可以從binlog日志中恢復(fù)。
- 配置較為簡單方便。
其劣勢為：
- 從庫要從binlog獲取數(shù)據(jù)并重放，這肯定與主庫寫入數(shù)據(jù)存在時間延遲，因此從庫的數(shù)據(jù)總是要滯后主庫。
- 對主庫與從庫之間的網(wǎng)絡(luò)延遲要求較高，若網(wǎng)絡(luò)延遲太高，將加重上述的滯后，造成最終數(shù)據(jù)的不一致。
- 單一的主節(jié)點(diǎn)掛了，將不能對外提供寫服務(wù)。
2，MySQL Fabirc
mysql織物（MySQL Fabirc），是mysql官方提供的。
這是在MySQL Replication的基礎(chǔ)上，增加了故障檢測與轉(zhuǎn)移，自動數(shù)據(jù)分片功能。不過依舊是一主多從的結(jié)構(gòu)，MySQL Fabirc只有一個主節(jié)點(diǎn)，區(qū)別是當(dāng)該主節(jié)點(diǎn)掛了以后，會從從節(jié)點(diǎn)中選擇一個來當(dāng)主節(jié)點(diǎn)。
就各個集群方案來說，其優(yōu)勢為：
- mysql官方提供的工具，無需第三方插件。
- 數(shù)據(jù)被刪除，可以從binlog日志中恢復(fù)。
- 主節(jié)點(diǎn)掛了以后，能夠自動從從節(jié)點(diǎn)中選擇一個來當(dāng)主節(jié)點(diǎn)，不影響持續(xù)對外提供寫服務(wù)。
其劣勢為：
- 從庫要從binlog獲取數(shù)據(jù)并重放，這肯定與主庫寫入數(shù)據(jù)存在時間延遲，因此從庫的數(shù)據(jù)總是要滯后主庫。
- 對主庫與從庫之間的網(wǎng)絡(luò)延遲要求較高，若網(wǎng)絡(luò)延遲太高，將加重上述的滯后，造成最終數(shù)據(jù)的不一致。
- 2014年5月推出的產(chǎn)品，數(shù)據(jù)庫資歷較淺，應(yīng)用案例不多，網(wǎng)上各種資料相對較少。
- 事務(wù)及查詢只支持在同一個分片內(nèi)，事務(wù)中更新的數(shù)據(jù)不能跨分片，查詢語句返回的數(shù)據(jù)也不能跨分片。
- 節(jié)點(diǎn)故障恢復(fù)30秒或更長（采用InnoDB存儲引擎的都這樣）。
3，MySQL Cluster
mysql集群（MySQL Cluster）也是mysql官方提供的。
MySQL Cluster是多主多從結(jié)構(gòu)的
就各個集群方案來說，其優(yōu)勢為：
- mysql官方提供的工具，無需第三方插件。
- 高可用性優(yōu)秀，99.999%的可用性，可以自動切分?jǐn)?shù)據(jù)，能跨節(jié)點(diǎn)冗余數(shù)據(jù)（其數(shù)據(jù)集并不是存儲某個特定的MySQL實(shí)例上，而是被分布在多個Data Nodes中，即一個table的數(shù)據(jù)可能被分散在多個物理節(jié)點(diǎn)上，任何數(shù)據(jù)都會在多個Data Nodes上冗余備份。任何一個數(shù)據(jù)變更操作，都將在一組Data Nodes上同步，以保證數(shù)據(jù)的一致性）。
- 可伸縮性優(yōu)秀，能自動切分?jǐn)?shù)據(jù)，方便數(shù)據(jù)庫的水平拓展。
- 負(fù)載均衡優(yōu)秀，可同時用于讀操作、寫操作都都密集的應(yīng)用，也可以使用SQL和NOSQL接口訪問數(shù)據(jù)。
- 多個主節(jié)點(diǎn)，沒有單點(diǎn)故障的問題，節(jié)點(diǎn)故障恢復(fù)通常小于1秒。
其劣勢為：
- 架構(gòu)模式和原理很復(fù)雜。
- 只能使用存儲引擎 NDB ，與平常使用的InnoDB 有很多明顯的差距。比如在事務(wù)（其事務(wù)隔離級別只支持Read Committed，即一個事務(wù)在提交前，查詢不到在事務(wù)內(nèi)所做的修改），外鍵（雖然最新的NDB 存儲引擎已經(jīng)支持外鍵，但性能有問題，因?yàn)橥怄I所關(guān)聯(lián)的記錄可能在別的分片節(jié)點(diǎn)），表限制上的不同，可能會導(dǎo)致日常開發(fā)出現(xiàn)意外。點(diǎn)擊查看具體差距比較
- 作為分布式的數(shù)據(jù)庫系統(tǒng)，各個節(jié)點(diǎn)之間存在大量的數(shù)據(jù)通訊，比如所有訪問都是需要經(jīng)過超過一個節(jié)點(diǎn)（至少有一個 SQL Node和一個 NDB Node）才能完成，因此對節(jié)點(diǎn)之間的內(nèi)部互聯(lián)網(wǎng)絡(luò)帶寬要求高。
- Data Node數(shù)據(jù)會被盡量放在內(nèi)存中，對內(nèi)存要求大，而且重啟的時候，數(shù)據(jù)節(jié)點(diǎn)將數(shù)據(jù)load到內(nèi)存需要很長時間。
官方的三兄弟的區(qū)別對比如下圖所示；
二，mysql第三方優(yōu)化
4，MMM
MMM是在MySQL Replication的基礎(chǔ)上，對其進(jìn)行優(yōu)化。
MMM（Master Replication Manager for MySQL）是雙主多從結(jié)構(gòu)，這是Google的開源項(xiàng)目，使用Perl語言來對MySQL Replication做擴(kuò)展，提供一套支持雙主故障切換和雙主日常管理的腳本程序，主要用來監(jiān)控mysql主主復(fù)制并做失敗轉(zhuǎn)移。
注意：這里的雙主節(jié)點(diǎn)，雖然叫做雙主復(fù)制，但是業(yè)務(wù)上同一時刻只允許對一個主進(jìn)行寫入，另一臺備選主上提供部分讀服務(wù)，以加速在主主切換時刻備選主的預(yù)熱。
就各個集群方案來說，其優(yōu)勢為：
- 自動的主主Failover切換，一般3s以內(nèi)切換備機(jī)。
- 多個從節(jié)點(diǎn)讀的負(fù)載均衡。
其劣勢為：
- 無法完全保證數(shù)據(jù)的一致性。如主1掛了，MMM monitor已經(jīng)切換到主2上來了，而若此時雙主復(fù)制中，主2數(shù)據(jù)落后于主1（即還未完全復(fù)制完畢），那么此時的主2已經(jīng)成為主節(jié)點(diǎn)，對外提供寫服務(wù)，從而導(dǎo)致數(shù)據(jù)不一。
- 由于是使用虛擬IP浮動技術(shù)，類似Keepalived，故RIP（真實(shí)IP）要和VIP（虛擬IP）在同一網(wǎng)段。如果是在不同網(wǎng)段也可以，需要用到虛擬路由技術(shù)。但是絕對要在同一個IDC機(jī)房，不可跨IDC機(jī)房組建集群。
5，MHA
MHA是在MySQL Replication的基礎(chǔ)上，對其進(jìn)行優(yōu)化。
MHA（Master High Availability）是多主多從結(jié)構(gòu)，這是日本DeNA公司的youshimaton開發(fā)，主要提供更多的主節(jié)點(diǎn)，但是缺少VIP（虛擬IP），需要配合keepalived等一起使用。
要搭建MHA，要求一個復(fù)制集群中必須最少有三臺數(shù)據(jù)庫服務(wù)器，一主二從，即一臺充當(dāng)master，一臺充當(dāng)備用master，另外一臺充當(dāng)從庫。
就各個集群方案來說，其優(yōu)勢為：
- 可以進(jìn)行故障的自動檢測和轉(zhuǎn)移
- 具備自動數(shù)據(jù)補(bǔ)償能力，在主庫異常崩潰時能夠最大程度的保證數(shù)據(jù)的一致性。
其劣勢為：
MHA架構(gòu)實(shí)現(xiàn)讀寫分離，最佳實(shí)踐是在應(yīng)用開發(fā)設(shè)計(jì)時提前規(guī)劃讀寫分離事宜，在使用時設(shè)置兩個連接池，即讀連接池與寫連接池，也可以選擇折中方案即引入SQL Proxy。但無論如何都需要改動代碼；
關(guān)于讀負(fù)載均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能實(shí)現(xiàn)負(fù)載均衡、故障檢查及備升級為主后的讀寫剝離功能即可，建議使用LVS
6，Galera Cluster
Galera Cluster是由Codership開發(fā)的MySQL多主結(jié)構(gòu)集群，這些主節(jié)點(diǎn)互為其它節(jié)點(diǎn)的從節(jié)點(diǎn)。不同于MySQL原生的主從異步復(fù)制，Galera采用的是多主同步復(fù)制，并針對同步復(fù)制過程中，會大概率出現(xiàn)的事務(wù)沖突和死鎖進(jìn)行優(yōu)化，就是復(fù)制不基于官方binlog而是Galera復(fù)制插件，重寫了wsrep api。
異步復(fù)制中，主庫將數(shù)據(jù)更新傳播給從庫后立即提交事務(wù)，而不論從庫是否成功讀取或重放數(shù)據(jù)變化。這種情況下，在主庫事務(wù)提交后的短時間內(nèi)，主從庫數(shù)據(jù)并不一致。
同步復(fù)制時，主庫的單個更新事務(wù)需要在所有從庫上同步 更新。換句話說，當(dāng)主庫提交事務(wù)時，集群中所有節(jié)點(diǎn)的數(shù)據(jù)保持一致。
對于讀操作，從每個節(jié)點(diǎn)讀取到的數(shù)據(jù)都是相同的。對于寫操作，當(dāng)數(shù)據(jù)寫入某一節(jié)點(diǎn)后，集群會將其同步到其它節(jié)點(diǎn)。
就各個集群方案來說，其優(yōu)勢為：
- 多主多活下，可對任一節(jié)點(diǎn)進(jìn)行讀寫操作，就算某個節(jié)點(diǎn)掛了，也不影響其它的節(jié)點(diǎn)的讀寫，都不需要做故障切換操作，也不會中斷整個集群對外提供的服務(wù)。
- 拓展性優(yōu)秀，新增節(jié)點(diǎn)會自動拉取在線節(jié)點(diǎn)的數(shù)據(jù)（當(dāng)有新節(jié)點(diǎn)加入時，集群會選擇出一個Donor Node為新節(jié)點(diǎn)提供數(shù)據(jù)），最終集群所有節(jié)點(diǎn)數(shù)據(jù)一致，而不需要手動備份恢復(fù)。
其劣勢為：
- 能做到數(shù)據(jù)的強(qiáng)一致性，毫無疑問，也是以犧牲性能為代價(jià)。
三，依托硬件配合
不同主機(jī)的數(shù)據(jù)同步不再依賴于MySQL的原生復(fù)制功能，而是通過同步磁盤數(shù)據(jù)，來保證數(shù)據(jù)的一致性。
然后處理故障的方式是借助Heartbeat，它監(jiān)控和管理各個節(jié)點(diǎn)間連接的網(wǎng)絡(luò)，并監(jiān)控集群服務(wù)，當(dāng)節(jié)點(diǎn)出現(xiàn)故障或者服務(wù)不可用時，自動在其他節(jié)點(diǎn)啟動集群服務(wù)。
7，heartbeat+SAN
SAN：共享存儲，主庫從庫用的一個存儲。SAN的概念是允許存儲設(shè)施和解決器（服務(wù)器）之間建立直接的高速連接，通過這種連接實(shí)現(xiàn)數(shù)據(jù)的集中式存儲。
就各個集群方案來說，其優(yōu)勢為：
保證數(shù)據(jù)的強(qiáng)一致性；
與mysql解耦，不會由于mysql的邏輯錯誤發(fā)生數(shù)據(jù)不一致的情況；
其劣勢為：
- SAN價(jià)格昂貴；
8，heartbeat+DRDB
DRDB：這是linux內(nèi)核板塊實(shí)現(xiàn)的快級別的同步復(fù)制技術(shù)。通過各主機(jī)之間的網(wǎng)絡(luò)，復(fù)制對方磁盤的內(nèi)容。當(dāng)客戶將數(shù)據(jù)寫入本地磁盤時，還會將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺主機(jī)的磁盤上，這樣的本地主機(jī)(主節(jié)點(diǎn))與遠(yuǎn)程主機(jī)(備節(jié)點(diǎn))的數(shù)據(jù)即可以保證明時同步。
就各個集群方案來說，其優(yōu)勢為：
相比于SAN儲存網(wǎng)絡(luò)，價(jià)格低廉；
保證數(shù)據(jù)的強(qiáng)一致性；
與mysql解耦，不會由于mysql的邏輯錯誤發(fā)生數(shù)據(jù)不一致的情況；
其劣勢為：
對io性能影響較大；
從庫不提供讀操作；
四，其它
9，Zookeeper + proxy
Zookeeper使用分布式算法保證集群數(shù)據(jù)的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網(wǎng)絡(luò)分區(qū)現(xiàn)象的產(chǎn)生。
就各個集群方案來說，其優(yōu)勢為：
- 擴(kuò)展性較好，可以擴(kuò)展為大規(guī)模集群。
缺其劣勢為：
- 搭建Zookeeper 集群，在配置一套代理，整個系統(tǒng)的邏輯變得更加復(fù)雜。
10，Paxos
分布式一致性算法，Paxos 算法處理的問題是一個分布式系統(tǒng)如何就某個值（決議）達(dá)成一致。這個算法被認(rèn)為是同類算法中最有效的。Paxos與MySQL相結(jié)合可以實(shí)現(xiàn)在分布式的MySQL數(shù)據(jù)的強(qiáng)一致性。
