从mysql高可用架构看高可用架构设计
高可用HA(High Availability)是分布式系統(tǒng)架構(gòu)設(shè)計中必須考慮的因素之一,它通常是指,通過設(shè)計減少系統(tǒng)不能提供服務(wù)的時間。
假設(shè)系統(tǒng)一直能夠提供服務(wù),我們說系統(tǒng)的可用性是100%。如果系統(tǒng)每運行100個時間單位,會有1個時間單位無法提供服務(wù),我們說系統(tǒng)的可用性是99%。很多公司的高可用目標(biāo)是4個9,也就是99.99%,這就意味著,系統(tǒng)的年停機時間為8.76個小時。
百度的搜索首頁,是業(yè)內(nèi)公認(rèn)高可用保障非常出色的系統(tǒng),甚至人們會通過www.baidu.com 能不能訪問來判斷“網(wǎng)絡(luò)的連通性”,百度高可用的服務(wù)讓人留下啦“網(wǎng)絡(luò)通暢,百度就能訪問”,“百度打不開,應(yīng)該是網(wǎng)絡(luò)連不上”的印象,這其實是對百度HA最高的褒獎。
1. mysql高可用
說到mysql的高可用,不得不提到復(fù)制,復(fù)制是 mysql高可用的基礎(chǔ)。復(fù)制解決了什么問題呢?
實現(xiàn)數(shù)據(jù)備份
如果有從服務(wù)器,主服務(wù)器發(fā)生故障之后,開通從服務(wù)器的寫入功能,從而提供高可用的使用功能
異地容災(zāi)
分?jǐn)傌撦d(scale out )主服務(wù)器:寫 ? ? ?從服務(wù)器:讀
1.1 主從復(fù)制流程
不同的復(fù)制協(xié)議
?
1.2.高可用復(fù)制架構(gòu)
1.3.mysql 高可用架構(gòu)
? 1.3.1?MySQL Cluster架構(gòu)
限制存儲引擎為NDB存儲引擎
?
1.3.2?MySQL+MMM架構(gòu)
MMM即Master-Master Replication Manager for MySQL(mysql主主復(fù)制管理器),是關(guān)于mysql主主復(fù)制配置的監(jiān)控、故障轉(zhuǎn)移和管理的一套可伸縮的腳本套件(在任何時候只有一個節(jié)點可以被寫入),這個套件也能基于標(biāo)準(zhǔn)的主從配置的任意數(shù)量的從服務(wù)器進行讀負載均衡,所以你可以用它來在一組居于復(fù)制的服務(wù)器啟動虛擬ip,除此之外,它還有實現(xiàn)數(shù)據(jù)備份、節(jié)點之間重新同步功能的腳本。
?MySQL本身沒有提供replication failover的解決方案,通過MMM方案能實現(xiàn)服務(wù)器的故障轉(zhuǎn)移,從而實現(xiàn)mysql的高可用。
此方案特點:
1、安全、穩(wěn)定性較高,可擴展性好
2、 對服務(wù)器數(shù)量要求至少三臺及以上
3、 對雙主(主從復(fù)制性要求較高)
4、 同樣可實現(xiàn)讀寫分離
1.3.3?MySQL+MHA架構(gòu)
MHA目前在Mysql高可用方案中應(yīng)該也是比較成熟和常見的方案,它由日本人開發(fā)出來,在mysql故障切換過程中,MHA能做到快速自動切換操作,而且還能最大限度保持?jǐn)?shù)據(jù)的一致性
此架構(gòu)特點:
1、安裝布署簡單,不影響現(xiàn)有架構(gòu)
2、自動監(jiān)控和故障轉(zhuǎn)移
3、保障數(shù)據(jù)一致性
4、故障切換方式可使用手動或自動多向選擇
5、適應(yīng)范圍大(適用任何存儲引擎)
?2.MySQL高可用帶給我們對高可用架構(gòu)設(shè)計的思考
為了保證數(shù)據(jù)的一致性,mysql提出了復(fù)制的概念。
為了滿足acid,mysql提供了兩種日志redo和undo日志,
redo log是重做日志,提供前滾操作,undo log是回滾日志,提供回滾操作。
undo log不是redo log的逆向過程,其實它們都算是用來恢復(fù)的日志:
redo log通常是物理日志,記錄的是數(shù)據(jù)頁的物理修改,而不是某一行或某幾行修改成怎樣怎樣,它用來恢復(fù)提交后的物理數(shù)據(jù)頁(恢復(fù)數(shù)據(jù)頁,且只能恢復(fù)到最后一次提交的位置)。
undo用來回滾行記錄到某個版本。undo log一般是邏輯日志,根據(jù)每行記錄進行記錄。
為了高可用的保證,有了多主或者主從切換。
? ? ? 數(shù)據(jù)庫的高可用架構(gòu)一般在系統(tǒng)的底層,這方面的技術(shù)要求比較高,整個高可用系統(tǒng)大致如下:
?
3.總結(jié)
我們都知道,單點是系統(tǒng)高可用的大敵,單點往往是系統(tǒng)高可用最大的風(fēng)險和敵人,應(yīng)該盡量在系統(tǒng)設(shè)計的過程中避免單點。
方法論上,高可用保證的原則是“集群化”,或者叫“冗余”:只有一個單點,掛了服務(wù)會受影響;如果有冗余備份,掛了還有其他backup能夠頂上。冗余的最大難道是一致性即復(fù)制技術(shù),mysql提供了一個思路。
有了冗余之后,還不夠,每次出現(xiàn)故障需要人工介入恢復(fù)勢必會增加系統(tǒng)的不可服務(wù)實踐。所以,又往往是通過“自動故障轉(zhuǎn)移”來實現(xiàn)系統(tǒng)的高可用。災(zāi)備的恢復(fù)一般通過日志來做,日志的設(shè)計也是難點,mysql提供了一個思路。
【1】http://uat.severalnines.com/blog/comparing-replication-solutions-oracle-and-mysql
【2】https://mysqlhighavailability.com/mysql-group-replication-hello-world/
【3】https://www.cnblogs.com/youkanyouxiao/p/8335159.html
【4】http://www.sohu.com/a/197271694_505827
【5】https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html
【6】https://www.cnblogs.com/youkanyouxiao/p/9834791.html
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/10909905.html
總結(jié)
以上是生活随笔為你收集整理的从mysql高可用架构看高可用架构设计的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 由mysql分区想到的分表分库的方案
- 下一篇: Retrofit分析-漂亮的解耦套路