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