




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡介
1、 UCLoud中國云三強(qiáng): 五大常見的MySQL高可用方案首發(fā)于大U的技術(shù)課堂1. 概述我們?cè)诳紤]MySQL數(shù)據(jù)庫的高可用的架構(gòu)時(shí),主要要考慮如下幾方面: 如果數(shù)據(jù)庫發(fā)生了宕機(jī)或者意外中斷等故障,能盡快恢復(fù)數(shù)據(jù)庫的可用性,盡可能的減少停機(jī)時(shí)間,保證業(yè)務(wù)不會(huì)因?yàn)閿?shù)據(jù)庫的故障而中斷。 用作備份、只讀副本等功能的非主節(jié)點(diǎn)的數(shù)據(jù)應(yīng)該和主節(jié)點(diǎn)的數(shù)據(jù)實(shí)時(shí)或者保持一致。 當(dāng)業(yè)務(wù)發(fā)生數(shù)據(jù)庫切換時(shí),切換前后的數(shù)據(jù)庫內(nèi)容應(yīng)當(dāng)一致,不會(huì)因?yàn)閿?shù)據(jù)缺失或者數(shù)據(jù)不一致而影響業(yè)務(wù)。關(guān)于對(duì)高可用的分級(jí)在這里我們不做詳細(xì)的討論,這里只討論常用高可用方案的優(yōu)缺點(diǎn)以及高可用方案的選型。2. 高可用方案2.1. 主從或主主半同步復(fù)制
2、使用雙節(jié)點(diǎn)數(shù)據(jù)庫,搭建單向或者雙向的半同步復(fù)制。在5.7以后的版本中,由于lossless replication、logical多線程復(fù)制等一些列新特性的引入,使得MySQL原生半同步復(fù)制更加可靠。常見架構(gòu)如下:通常會(huì)和proxy、keepalived等第三方軟件同時(shí)使用,即可以用來監(jiān)控?cái)?shù)據(jù)庫的健康,又可以執(zhí)行一系列管理命令。如果主庫發(fā)生故障,切換到備庫后仍然可以繼續(xù)使用數(shù)據(jù)庫。優(yōu)點(diǎn):1. 架構(gòu)比較簡單,使用原生半同步復(fù)制作為數(shù)據(jù)同步的依據(jù);2. 雙節(jié)點(diǎn),沒有主機(jī)宕機(jī)后的選主問題,直接切換即可;3. 雙節(jié)點(diǎn),需求資源少,部署簡單;缺點(diǎn):1. 完全依賴于半同步復(fù)制,如果半同步復(fù)制退化為異步復(fù)制
3、,數(shù)據(jù)一致性無法得到保證;2. 需要額外考慮haproxy、keepalived的高可用機(jī)制。2.2. 半同步復(fù)制優(yōu)化半同步復(fù)制機(jī)制是可靠的。如果半同步復(fù)制一直是生效的,那么便可以認(rèn)為數(shù)據(jù)是一致的。但是由于網(wǎng)絡(luò)波動(dòng)等一些客觀原因,導(dǎo)致半同步復(fù)制發(fā)生超時(shí)而切換為異步復(fù)制,那么這時(shí)便不能保證數(shù)據(jù)的一致性。所以盡可能的保證半同步復(fù)制,便可提高數(shù)據(jù)的一致性。該方案同樣使用雙節(jié)點(diǎn)架構(gòu),但是在原有半同復(fù)制的基礎(chǔ)上做了功能上的優(yōu)化,使半同步復(fù)制的機(jī)制變得更加可靠。可參考的優(yōu)化方案如下:2.2.1. 雙通道復(fù)制半同步復(fù)制由于發(fā)生超時(shí)后,復(fù)制斷開,當(dāng)再次建立起復(fù)制時(shí),同時(shí)建立兩條通道,其中一條半同步復(fù)制通道從當(dāng)
4、前位置開始復(fù)制,保證從機(jī)知道當(dāng)前主機(jī)執(zhí)行的進(jìn)度。另外一條異步復(fù)制通道開始追補(bǔ)從機(jī)落后的數(shù)據(jù)。當(dāng)異步復(fù)制通道追趕到半同步復(fù)制的起始位置時(shí),恢復(fù)半同步復(fù)制。2.2.2. binlog文件服務(wù)器搭建兩條半同步復(fù)制通道,其中連接文件服務(wù)器的半同步通道正常情況下不啟用,當(dāng)主從的半同步復(fù)制發(fā)生網(wǎng)絡(luò)問題退化后,啟動(dòng)與文件服務(wù)器的半同步復(fù)制通道。當(dāng)主從半同步復(fù)制恢復(fù)后,關(guān)閉與文件服務(wù)器的半同步復(fù)制通道。優(yōu)點(diǎn):1. 雙節(jié)點(diǎn),需求資源少,部署簡單;2. 架構(gòu)簡單,沒有選主的問題,直接切換即可;3. 相比于原生復(fù)制,優(yōu)化后的半同步復(fù)制更能保證數(shù)據(jù)的一致性。缺點(diǎn):1. 需要修改內(nèi)核源碼或者使用mysql通信協(xié)議。需要
5、對(duì)源碼有一定的了解,并能做一定程度的二次開發(fā)。2. 依舊依賴于半同步復(fù)制,沒有從根本上解決數(shù)據(jù)一致性問題。2.3. 高可用架構(gòu)優(yōu)化將雙節(jié)點(diǎn)數(shù)據(jù)庫擴(kuò)展到多節(jié)點(diǎn)數(shù)據(jù)庫,或者多節(jié)點(diǎn)數(shù)據(jù)庫集群??梢愿鶕?jù)自己的需要選擇一主兩從、一主多從或者多主多從的集群。由于半同步復(fù)制,存在接收到一個(gè)從機(jī)的成功應(yīng)答即認(rèn)為半同步復(fù)制成功的特性,所以多從半同步復(fù)制的可靠性要優(yōu)于單從半同步復(fù)制的可靠性。并且多節(jié)點(diǎn)同時(shí)宕機(jī)的幾率也要小于單節(jié)點(diǎn)宕機(jī)的幾率,所以多節(jié)點(diǎn)架構(gòu)在一定程度上可以認(rèn)為高可用性是好于雙節(jié)點(diǎn)架構(gòu)。但是由于數(shù)據(jù)庫數(shù)量較多,所以需要數(shù)據(jù)庫管理軟件來保證數(shù)據(jù)庫的可維護(hù)性??梢赃x擇MMM、MHA或者各個(gè)版本的proxy
6、等等。常見方案如下:2.3.1. MHA+多節(jié)點(diǎn)集群MHA Manager會(huì)定時(shí)探測(cè)集群中的master節(jié)點(diǎn),當(dāng)master出現(xiàn)故障時(shí),它可以自動(dòng)將新數(shù)據(jù)的slave提升為新的master,然后將所有其他的slave重新指向新的master,整個(gè)故障轉(zhuǎn)移過程對(duì)應(yīng)用程序完全透明。MHA Node運(yùn)行在每臺(tái)MySQL服務(wù)器上,主要作用是切換時(shí)處理二進(jìn)制日志,確保切換盡量少丟數(shù)據(jù)。MHA也可以擴(kuò)展到如下的多節(jié)點(diǎn)集群:優(yōu)點(diǎn):1. 可以進(jìn)行故障的自動(dòng)檢測(cè)和轉(zhuǎn)移;2. 可擴(kuò)展性較好,可以根據(jù)需要擴(kuò)展MySQL的節(jié)點(diǎn)數(shù)量和結(jié)構(gòu);3. 相比于雙節(jié)點(diǎn)的MySQL復(fù)制,三節(jié)點(diǎn)/多節(jié)點(diǎn)的MySQL發(fā)生不可用的概率更
7、低缺點(diǎn):1. 至少需要三節(jié)點(diǎn),相對(duì)于雙節(jié)點(diǎn)需要更多的資源;2. 邏輯較為復(fù)雜,發(fā)生故障后排查問題,定位問題更加困難;3. 數(shù)據(jù)一致性仍然靠原生半同步復(fù)制保證,仍然存在數(shù)據(jù)不一致的風(fēng)險(xiǎn);4. 可能因?yàn)榫W(wǎng)絡(luò)分區(qū)發(fā)生腦裂現(xiàn)象;2.3.2. zookeeper+proxyZookeeper使用分布式算法保證集群數(shù)據(jù)的一致性,使用zookeeper可以有效的保證proxy的高可用性,可以較好的避免網(wǎng)絡(luò)分區(qū)現(xiàn)象的產(chǎn)生。優(yōu)點(diǎn):1. 較好的保證了整個(gè)系統(tǒng)的高可用性,包括proxy、MySQL;2. 擴(kuò)展性較好,可以擴(kuò)展為大規(guī)模集群;缺點(diǎn):1. 數(shù)據(jù)一致性仍然依賴于原生的mysql半同步復(fù)制;2. 引入zk,整
8、個(gè)系統(tǒng)的邏輯變得更加復(fù)雜;2.4. 共享存儲(chǔ)共享存儲(chǔ)實(shí)現(xiàn)了數(shù)據(jù)庫服務(wù)器和存儲(chǔ)設(shè)備的解耦,不同數(shù)據(jù)庫之間的數(shù)據(jù)同步不再依賴于MySQL的原生復(fù)制功能,而是通過磁盤數(shù)據(jù)同步的手段,來保證數(shù)據(jù)的一致性。2.4.1. SAN共享儲(chǔ)存SAN的概念是允許存儲(chǔ)設(shè)備和處理器(服務(wù)器)之間建立直接的高速網(wǎng)絡(luò)(與LAN相比)連接,通過這種連接實(shí)現(xiàn)數(shù)據(jù)的集中式存儲(chǔ)。常用架構(gòu)如下:使用共享存儲(chǔ)時(shí),MySQL服務(wù)器能夠正常掛載文件系統(tǒng)并操作,如果主庫發(fā)生宕機(jī),備庫可以掛載相同的文件系統(tǒng),保證主庫和備庫使用相同的數(shù)據(jù)。優(yōu)點(diǎn):1. 兩節(jié)點(diǎn)即可,部署簡單,切換邏輯簡單;2. 很好的保證數(shù)據(jù)的強(qiáng)一致性;3. 不會(huì)因?yàn)镸ySQL
9、的邏輯錯(cuò)誤發(fā)生數(shù)據(jù)不一致的情況;缺點(diǎn):1. 需要考慮共享存儲(chǔ)的高可用;2. 價(jià)格昂貴;2.4.2. DRBD磁盤復(fù)制DRBD是一種基于軟件、基于網(wǎng)絡(luò)的塊復(fù)制存儲(chǔ)解決方案,主要用于對(duì)服務(wù)器之間的磁盤、分區(qū)、邏輯卷等進(jìn)行數(shù)據(jù)鏡像,當(dāng)用戶將數(shù)據(jù)寫入本地磁盤時(shí),還會(huì)將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺(tái)主機(jī)的磁盤上,這樣的本地主機(jī)(主節(jié)點(diǎn))與遠(yuǎn)程主機(jī)(備節(jié)點(diǎn))的數(shù)據(jù)就可以保證實(shí)時(shí)同步。常用架構(gòu)如下:當(dāng)本地主機(jī)出現(xiàn)問題,遠(yuǎn)程主機(jī)上還保留著一份相同的數(shù)據(jù),可以繼續(xù)使用,保證了數(shù)據(jù)的安全。DRBD是linux內(nèi)核模塊實(shí)現(xiàn)的快級(jí)別的同步復(fù)制技術(shù),可以與SAN達(dá)到相同的共享存儲(chǔ)效果。優(yōu)點(diǎn):1. 兩節(jié)點(diǎn)即可,部署簡單,切換邏輯
10、簡單;2. 相比于SAN儲(chǔ)存網(wǎng)絡(luò),價(jià)格低廉;3. 保證數(shù)據(jù)的強(qiáng)一致性;缺點(diǎn):1. 對(duì)io性能影響較大;2. 從庫不提供讀操作;2.5. 分布式協(xié)議分布式協(xié)議可以很好解決數(shù)據(jù)一致性問題。比較常見的方案如下:2.5.1. MySQL clusterMySQL cluster是官方集群的部署方案,通過使用NDB存儲(chǔ)引擎實(shí)時(shí)備份冗余數(shù)據(jù),實(shí)現(xiàn)數(shù)據(jù)庫的高可用性和數(shù)據(jù)一致性。優(yōu)點(diǎn):1. 全部使用官方組件,不依賴于第三方軟件;2. 可以實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致性;缺點(diǎn):1. 國內(nèi)使用的較少;2. 配置較復(fù)雜,需要使用NDB儲(chǔ)存引擎,與MySQL常規(guī)引擎存在一定差異;3. 至少三節(jié)點(diǎn);2.5.2. Galera基于G
11、alera的MySQL高可用集群, 是多主數(shù)據(jù)同步的MySQL集群解決方案,使用簡單,沒有單點(diǎn)故障,可用性高。常見架構(gòu)如下:優(yōu)點(diǎn):1. 多主寫入,無延遲復(fù)制,能保證數(shù)據(jù)強(qiáng)一致性;2. 有成熟的社區(qū),有互聯(lián)網(wǎng)公司在大規(guī)模的使用;3. 自動(dòng)故障轉(zhuǎn)移,自動(dòng)添加、剔除節(jié)點(diǎn);缺點(diǎn):1. 需要為原生MySQL節(jié)點(diǎn)打wsrep補(bǔ)丁2. 只支持innodb儲(chǔ)存引擎3. 至少三節(jié)點(diǎn);2.5.3. POAXSPaxos 算法解決的問題是一個(gè)分布式系統(tǒng)如何就某個(gè)值(決議)達(dá)成一致。這個(gè)算法被認(rèn)為是同類算法中比較有效的。Paxos與MySQL相結(jié)合可以實(shí)現(xiàn)在分布式的MySQL數(shù)據(jù)的強(qiáng)一致性。常見架構(gòu)如下:優(yōu)點(diǎn):1. 多主寫入,無延遲復(fù)制,能保證數(shù)據(jù)強(qiáng)一致性;2. 有成熟理論基礎(chǔ);3. 自動(dòng)故障轉(zhuǎn)移,自動(dòng)添加、剔除節(jié)點(diǎn);缺點(diǎn):1. 只支持innodb儲(chǔ)存引擎2. 至少三節(jié)點(diǎn);3. 總結(jié)隨著人們對(duì)數(shù)據(jù)一致性的要求不斷的提高,越來越多的方法被嘗試用來解決分布式數(shù)據(jù)一致性的問題,如MySQL自身的優(yōu)化、MySQL集群架構(gòu)的優(yōu)化、Paxos、Raft、2PC算法的引入等等。而使用分布式算法用來解決MySQL數(shù)據(jù)庫數(shù)據(jù)一致性的問題的方法,也越來越被人們所接受,一系列成熟的產(chǎn)品如Ph
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 茅臺(tái)酒戰(zhàn)略市場規(guī)劃報(bào)告
- 前期接入服務(wù)合同范本模板
- 公租房置換合同范本
- 歷制作合同范本
- 廚房冰箱轉(zhuǎn)讓合同范例
- 食堂托管經(jīng)營合同范本
- 云南公路合同范本
- 獸醫(yī)傳染病學(xué)試題庫含答案
- 醫(yī)療服務(wù)合同范例隱私
- 司機(jī)補(bǔ)充協(xié)議合同范本
- 大學(xué)生必知的自然科學(xué)知識(shí)考試題庫(300題)
- 煤層氣開發(fā)第7章煤層氣集輸課件
- 中西醫(yī)結(jié)合腫瘤學(xué)試卷
- 一年級(jí)下冊(cè)勞動(dòng)課教案5篇
- 特殊工種操作人員體檢表
- 常用橋牌詞語(中英文對(duì)照)
- 加盟招商方案PPT模板
- 中石油HSE培訓(xùn)試題集(共33頁)
- 噴(烤)漆房VOCs治理設(shè)施日常運(yùn)行臺(tái)賬
- 往復(fù)式壓縮機(jī)組單機(jī)試運(yùn)方案
- 區(qū)域環(huán)境概況
評(píng)論
0/150
提交評(píng)論