下面一起來(lái)了解下用MHA架構(gòu)實(shí)現(xiàn)MySQL高可用方法，相信大家看完肯定會(huì)受益匪淺，文字在精不在多，希望用MHA架構(gòu)實(shí)現(xiàn)MySQL高可用方法這篇短內(nèi)容是你想要的。

創(chuàng)新互聯(lián)是一家專注于成都網(wǎng)站制作、做網(wǎng)站與策劃設(shè)計(jì),舟山網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)10年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:舟山等地區(qū)。舟山做網(wǎng)站價(jià)格咨詢:18980820575

MySQL復(fù)制是異步或者半同步的。當(dāng)master故障時(shí)，一些slave可能并沒(méi)有收到最新的relay log，也就意味著每個(gè)slave可能處于不同的狀態(tài)。手動(dòng)處理這些一致性問(wèn)題是小事，因?yàn)椴恍迯?fù)這些問(wèn)題，就不能開(kāi)始復(fù)制。但是手動(dòng)修復(fù)這些問(wèn)題，花費(fèi)一個(gè)小時(shí)或更多的時(shí)間并不少見(jiàn)。

一主一從  

如果架構(gòu)是一主一從，就不會(huì)出現(xiàn)一部分slave的狀態(tài)落后于最新的slave的問(wèn)題。當(dāng)master出現(xiàn)故障，可以將應(yīng)用的流量全部發(fā)送給新的master（原來(lái)的slave）。故障切換很容易解決。但是會(huì)有下面的問(wèn)題。

首先，不能擴(kuò)展讀流量。在很多情況下，可能會(huì)運(yùn)行一些重要的操作，比如備份、分析查詢、批量處理。這可能會(huì)導(dǎo)致slave的性能問(wèn)題。如果只要一個(gè)slave，當(dāng)這個(gè)slave出現(xiàn)故障后，master必須處理所有這些流量。 

其次，可用性問(wèn)題。如果master出現(xiàn)故障，只剩下一臺(tái)服務(wù)（原來(lái)的slave成為主），就成為了單點(diǎn)故障問(wèn)題。為了創(chuàng)建一個(gè)新的slave，需要在線備份，然后存儲(chǔ)到新的slave上并立即啟動(dòng)slave。但是這些操作通常會(huì)花費(fèi)數(shù)小時(shí)（甚至是不止一天才能完成復(fù)制）。在一些重要的應(yīng)用上，可能忍受不了數(shù)據(jù)庫(kù)這么長(zhǎng)時(shí)間有單點(diǎn)故障問(wèn)題。并且，在線備份會(huì)大大增加master的I/O負(fù)載，因此在高峰期進(jìn)行備份是很危險(xiǎn)的。

雙主多從

雙主多從也是常見(jiàn)的架構(gòu)。如果當(dāng)前的master出現(xiàn)故障，備用的master就會(huì)變?yōu)樾耺aster。大很多場(chǎng)景下，備用的master都配置為只讀。 

但這不總是作為master故障切換解決方案運(yùn)行的。當(dāng)目前的master出現(xiàn)故障，余下的slave可能沒(méi)有接收到全部的relay log，因此在slave之間解決一致性問(wèn)題仍需要其它解決方案。 

如果不能忍受一致性問(wèn)題并且還想立即啟動(dòng)服務(wù)。只需要將備用的master作為新的master，并且拋棄剩余的slave。之后再?gòu)倪@個(gè)新的master做線上備份創(chuàng)建新的slave。但是這個(gè)方法和前面提到的一主一從的發(fā)法有同樣的問(wèn)題。剩余的slave不能進(jìn)行讀擴(kuò)展和進(jìn)行冗余的目的。 

另外，使用雙主（一個(gè)只讀）并且每個(gè)master都至少有一個(gè)從也是可能的。

至少一個(gè)從可以進(jìn)行復(fù)制，如果目前的master出現(xiàn)故障。但是事實(shí)上，很多使用者都不會(huì)采用這種架構(gòu)，因?yàn)樽畲蟮娜秉c(diǎn)是復(fù)雜性。在這種架構(gòu)中使用了三層復(fù)制。管理三層復(fù)制并不容易。例如，如果備用master出現(xiàn)故障，備用master的slave就無(wú)法繼續(xù)進(jìn)行復(fù)制。很多情況下，必須重新配置備用master和它的slave。重要的是，在這種架構(gòu)中，必須要使用至少4臺(tái)云服務(wù)器。 

心跳+DRBD 

使用心跳（Heartbeat）+DRBD+MySQL是非常常見(jiàn)的HA解決方案。但是這個(gè)解決方案有一些嚴(yán)重的問(wèn)題。

第一個(gè)問(wèn)題是開(kāi)銷，特別是想運(yùn)行大量MySQL復(fù)制環(huán)境的時(shí)候。心跳+DRBD是主用/備用解決方案，因此需要一個(gè)不處理任何應(yīng)用流量的被動(dòng)（standby）master。被動(dòng)云服務(wù)器不能被用來(lái)進(jìn)行讀擴(kuò)展。通常，你至少需要4臺(tái)MySQL服務(wù)，一個(gè)主動(dòng)(active)master，一個(gè)被動(dòng)(passive)master，兩個(gè)slave。

第二個(gè)問(wèn)題是停機(jī)。因?yàn)樾奶?Heartbeat是active/standby集群，因此如果active server出現(xiàn)故障，故障恢復(fù)會(huì)發(fā)生在passive server上。這可能需要花費(fèi)很長(zhǎng)的時(shí)間，特別是沒(méi)有用InnoDB插件。即使使用了InnoDB插件，只花費(fèi)幾分鐘在passive server開(kāi)始接收訪問(wèn)連接的情況并不常見(jiàn)。除了故障恢復(fù)時(shí)間，在故障恢復(fù)后，熱身（warm-up）（填充數(shù)據(jù)到緩沖池）也要花費(fèi)時(shí)間，因?yàn)樵趐assive上，數(shù)據(jù)庫(kù)/文件系統(tǒng)緩存是空的。在實(shí)際中，需要一個(gè)或更多額外的slave來(lái)處理足夠的讀流量。在warm-up期間，由于還粗是空的，因此寫性能會(huì)顯著下降。

第三個(gè)問(wèn)題是寫性能下降或一致性問(wèn)題。為了保證active/passive高可用集群運(yùn)行，在每次commit必須把事務(wù)日志(二進(jìn)制日志和InnoDB日志)刷新到磁盤，因此必須設(shè)置innodb-flush-log-at-trx-cmmit=1和sync-binlog=1。但是sync-binlog=1會(huì)降低寫性能，因?yàn)樵诋?dāng)前的MySQL版本fsync()是連續(xù)的（如果sync-binlog是1，組提交就會(huì)打破）。大多數(shù)情況下，不會(huì)設(shè)置sync-binlog=1。但是如果sync-binlog=1沒(méi)有設(shè)置，當(dāng)active master故障，新的master（之前的passive server）可能會(huì)丟失已經(jīng)被發(fā)送到slave上的二進(jìn)制日志事件。假如，master出現(xiàn)故障，并且slave A接收到mysql-bin.00123的1500位置。如果binlog數(shù)據(jù)近刷新到1000位置到磁盤，新的master僅只有mysql-bin.00123到1000位置并且創(chuàng)建新的二進(jìn)制文件mysql-bin.00124。如果出現(xiàn)這種情況，由于新的master沒(méi)有mysql-bin.00123的1500位置，slave A就不能進(jìn)行復(fù)制了。

第四個(gè)問(wèn)題是復(fù)雜性。對(duì)于很多用戶來(lái)說(shuō)，安裝/配置心跳和DRBD是不簡(jiǎn)單的。在很多部署環(huán)境，配置DRBD經(jīng)常需要重建系統(tǒng)分區(qū)，這在很多情況下是不容易的。另外，也需要在DRBD和Linux內(nèi)核層有足夠的經(jīng)驗(yàn)。如果執(zhí)行了一個(gè)錯(cuò)誤的命令（比如在passive節(jié)點(diǎn)執(zhí)行了drbd –overwrite-data-of-peer）非常容易損壞生產(chǎn)數(shù)據(jù)。當(dāng)使用DRBD，一旦出現(xiàn)磁盤I/O層的問(wèn)題，對(duì)于大多數(shù)DBA來(lái)說(shuō)，解決這個(gè)問(wèn)題是很難的。

MySQL集群 

MySQL集群真正實(shí)現(xiàn)了高可用解決方案，但是必須使用NDB存儲(chǔ)引擎。大多數(shù)情況下都是使用InnoDB，因此無(wú)法使用MySQL集群的優(yōu)勢(shì)。

• 半同步復(fù)制 

半同步復(fù)制大大降低了”binlog僅存在故障master上”的風(fēng)險(xiǎn)。這對(duì)避免數(shù)據(jù)的丟失有很大的幫助。但是半同步復(fù)制并沒(méi)有解決一致性問(wèn)題。半同步復(fù)制保證在master提交時(shí)至少有一個(gè)（并不是所有）slave接收到binlog事件。仍有可能一些slave沒(méi)有接收到binlog事件。如果沒(méi)有將最新的slave上的relay log應(yīng)用到非最新的slave上，slave就無(wú)法處于一致性狀態(tài)。

MHA解決了一致性問(wèn)題，因此通過(guò)將半同步復(fù)制和MHA一起使用，幾乎沒(méi)有數(shù)據(jù)丟失和slave保持一直就能實(shí)現(xiàn)。

全局事務(wù)ID（GTID）

全局事務(wù)ID的目的和MHA想要實(shí)現(xiàn)的是基本相同的，但是全局事務(wù)ID包括的更多。MHA只能支持兩層復(fù)制，但是全局事務(wù)ID可以支持很多層復(fù)制的環(huán)境，因此即使第二層復(fù)制故障了，仍然可以恢復(fù)三層復(fù)制。

從MySQL5.6開(kāi)始就開(kāi)始支持GTID了。Oracle的官方工具mysqlfailover支持帶GTID的master故障切換。從MHA的0.56版本開(kāi)始，也支持基于GTID的故障切換。MHA會(huì)自動(dòng)檢測(cè)mysqld是否在GTID運(yùn)行，如果GTID開(kāi)啟，MHA就實(shí)現(xiàn)帶GTmysql數(shù)據(jù)庫(kù)指定條數(shù)數(shù)據(jù)查詢的主要方法ID的故障切換，如果沒(méi)有啟用，MHA就使用基于relay log的故障切換。

看完用MHA架構(gòu)實(shí)現(xiàn)MySQL高可用方法這篇文章后，很多讀者朋友肯定會(huì)想要了解更多的相關(guān)內(nèi)容，如需獲取更多的行業(yè)信息，可以關(guān)注我們的行業(yè)資訊欄目。

新聞標(biāo)題：用MHA架構(gòu)實(shí)現(xiàn)MySQL高可用方法
本文網(wǎng)址：http://m.newbst.com/article14/gohede.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、外貿(mào)建站、網(wǎng)站維護(hù)、網(wǎng)站營(yíng)銷、做網(wǎng)站、網(wǎng)站改版

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)