MySQL高可用各個(gè)技術(shù)的比較
圖片和資料來(lái)源于MYSQL大牛姜承堯老師（MYSQL技術(shù)內(nèi)幕作者）。
數(shù)據(jù)庫(kù)的可靠指的是數(shù)據(jù)可靠；數(shù)據(jù)庫(kù)可用指的是數(shù)據(jù)庫(kù)服務(wù)可用。可靠的是數(shù)據(jù)就例如工商銀行，數(shù)據(jù)不能丟失；可用的是服務(wù)則指服務(wù)器不能宕機(jī)。
靈活運(yùn)用MYSQL的各種高可用技術(shù)來(lái)達(dá)到下面各種級(jí)別的高可用要求
要達(dá)到99.9%：使用MYSQL復(fù)制技術(shù)
要達(dá)到99.99%：使用MYSQL NDB 集群和虛擬化技術(shù)
要達(dá)到99.999%：使用shared-nothing架構(gòu)的GEO-REPLICATION和NDB集群技術(shù)
Gluster Geo-replication是什么?
Gluster Geo-replication(簡(jiǎn)稱geo-replication)是一種異地災(zāi)備技術(shù)，它主要應(yīng)用于把集群中的一個(gè)存儲(chǔ)，近乎即時(shí)地(near real-time)透過(guò)公網(wǎng)(wan)備份到遠(yuǎn)端的機(jī)房。
各種高可用級(jí)別允許的宕機(jī)時(shí)間
DRBD：網(wǎng)絡(luò)磁盤(pán)的RAID1
#p#
方案一：MYSQL主從復(fù)制(單活)
- 投票選舉機(jī)制較復(fù)雜
- MySQL本身沒(méi)有提供replication failover的解決方案，自動(dòng)切換需要依賴MHA腳本
- 可以有多臺(tái)從庫(kù)，從庫(kù)可以做報(bào)表和備份
方案二：雙主(單活)，failover比單主簡(jiǎn)單
同樣，自動(dòng)切換需要MMM腳本，缺點(diǎn)是某個(gè)主掛掉了，他下面的slave同樣掛掉。
#p#
方案三：雙主配SAN存儲(chǔ)(單活)
這個(gè)架構(gòu)跟方案二是一樣的，只不過(guò)兩個(gè)master之間不需要同步數(shù)據(jù)，因?yàn)樗麄冇玫氖枪蚕泶疟P(pán)，這個(gè)方案是有錢(qián)人方案，無(wú)論哪個(gè)主掛掉都不會(huì)引起其他的slave掛掉，但是SAN存儲(chǔ)死貴。。
像通信行業(yè)中國(guó)聯(lián)通這些公司有用到，某個(gè)主掛掉了，下面的slave不會(huì)掛掉。
注意：failover之后不會(huì)預(yù)熱，數(shù)據(jù)沒(méi)有預(yù)先加載到內(nèi)存中，切換之后一段時(shí)間內(nèi)存儲(chǔ)會(huì)有一定的性能影響
方案四：DRBD 雙主配DRBD (單活)
結(jié)構(gòu)跟方案三一樣，***不同的是沒(méi)有使用SAN網(wǎng)絡(luò)存儲(chǔ) ，而是使用local disk。由于是實(shí)時(shí)復(fù)制磁盤(pán)數(shù)據(jù)，性能會(huì)有影響。人們把DRBD稱為“屌絲的SAN”；POOR MAN'S SAN：窮人的SAN
#p#
方案五：NDB CLUSTER
國(guó)內(nèi)用NDB集群的公司非常少，貌似有些銀行有用。NDB集群不需要依賴第三方組件，全部都使用官方組件，能保證數(shù)據(jù)的一致性，某個(gè)數(shù)據(jù)節(jié)點(diǎn)掛掉，其他數(shù)據(jù)節(jié)點(diǎn)依然可以提供服務(wù)，管理節(jié)點(diǎn)需要做冗余以防掛掉。
缺點(diǎn)是：管理和配置都很復(fù)雜，而且某些SQL語(yǔ)句例如join語(yǔ)句需要避免。
方案六：第三方的Tungsten軟件
使用java編寫(xiě)，不是MYSQL內(nèi)置的，同樣是MYSQL數(shù)據(jù)庫(kù)復(fù)制，不過(guò)他不是用MYSQL內(nèi)置的組件來(lái)做的，不但支持MYSQL數(shù)據(jù)庫(kù)復(fù)制也支持異構(gòu)數(shù)據(jù)庫(kù)的復(fù)制，而且對(duì)異構(gòu)數(shù)據(jù)庫(kù)復(fù)制支持較好，例如MYSQL復(fù)制到ORACLE。
方案七：網(wǎng)易的INNOSQL
類似于SQLSERVER的鏡像高安全模式，High Safety 模式 (也就是同步模式)沒(méi)有 witness服務(wù)器。
數(shù)據(jù)庫(kù)在Principle的事務(wù)，需要馬上得到mirror的確認(rèn)，才能完成。這種情況下，Mirror和Principle的數(shù)據(jù)是同步的。
但是因?yàn)樗械氖聞?wù)需要mirror的確認(rèn)，所以性能可能會(huì)有所影響。
區(qū)別：innosql的slave可以讀，鏡像的slave(從庫(kù))不可讀。保證數(shù)據(jù)不會(huì)丟失，數(shù)據(jù)的高可靠性。
mysql5.7開(kāi)始支持這種模式
總結(jié)
每種方案都有不同的特點(diǎn)，配置和應(yīng)用場(chǎng)景也各有不同，有些偏向于成本低的，有些偏向于成本高的，有些偏向于數(shù)據(jù)的可靠性，有些則偏向于數(shù)據(jù)庫(kù)的可用性。反正各個(gè)方案都各有優(yōu)缺點(diǎn)，DBA要結(jié)合自己公司的業(yè)務(wù)情況進(jìn)行選擇合適自己業(yè)務(wù)情況的高可用方案。
