高可用HA（High Availability）是分布式系統(tǒng)架構(gòu)設計中必須考慮的因素之一，它通常是指，通過設計減少系統(tǒng)不能提供服務的時間。

假設系統(tǒng)一直能夠提供服務，我們說系統(tǒng)的可用性是100%。如果系統(tǒng)每運行100個時間單位，會有1個時間單位無法提供服務，我們說系統(tǒng)的可用性是99%。很多公司的高可用目標是4個9，也就是99.99%，這就意味著，系統(tǒng)的年停機時間為8.76個小時。

百度的搜索首頁，是業(yè)內(nèi)公認高可用保障非常出色的系統(tǒng)，甚至人們會通過www.baidu.com 能不能訪問來判斷“網(wǎng)絡的連通性”，百度高可用的服務讓人留下啦“網(wǎng)絡通暢，百度就能訪問”，“百度打不開，應該是網(wǎng)絡連不上”的印象，這其實是對百度HA最高的褒獎。

1. mysql高可用

說到mysql的高可用，不得不提到復制，復制是 mysql高可用的基礎。復制解決了什么問題呢？

實現(xiàn)數(shù)據(jù)備份

如果有從服務器，主服務器發(fā)生故障之后，開通從服務器的寫入功能，從而提供高可用的使用功能

異地容災

分攤負載（scale out ）主服務器：寫 ? ? ?從服務器：讀

1.1 主從復制流程

不同的復制協(xié)議

?

1.2.高可用復制架構(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主主復制管理器），是關(guān)于mysql主主復制配置的監(jiān)控、故障轉(zhuǎn)移和管理的一套可伸縮的腳本套件（在任何時候只有一個節(jié)點可以被寫入），這個套件也能基于標準的主從配置的任意數(shù)量的從服務器進行讀負載均衡，所以你可以用它來在一組居于復制的服務器啟動虛擬ip，除此之外，它還有實現(xiàn)數(shù)據(jù)備份、節(jié)點之間重新同步功能的腳本。
?MySQL本身沒有提供replication failover的解決方案，通過MMM方案能實現(xiàn)服務器的故障轉(zhuǎn)移，從而實現(xiàn)mysql的高可用。

此方案特點：

1、安全、穩(wěn)定性較高，可擴展性好

2、 對服務器數(shù)量要求至少三臺及以上

3、 對雙主（主從復制性要求較高）

4、 同樣可實現(xiàn)讀寫分離

1.3.3?MySQL+MHA架構(gòu)

MHA目前在Mysql高可用方案中應該也是比較成熟和常見的方案，它由日本人開發(fā)出來，在mysql故障切換過程中，MHA能做到快速自動切換操作，而且還能最大限度保持數(shù)據(jù)的一致性

此架構(gòu)特點：

1、安裝布署簡單，不影響現(xiàn)有架構(gòu)

2、自動監(jiān)控和故障轉(zhuǎn)移

3、保障數(shù)據(jù)一致性

4、故障切換方式可使用手動或自動多向選擇

5、適應范圍大（適用任何存儲引擎）

?2.MySQL高可用帶給我們對高可用架構(gòu)設計的思考

　　為了保證數(shù)據(jù)的一致性，mysql提出了復制的概念。

　　為了滿足acid，mysql提供了兩種日志redo和undo日志，

　　　　redo log是重做日志，提供前滾操作，undo log是回滾日志，提供回滾操作。
　　　　undo log不是redo log的逆向過程，其實它們都算是用來恢復的日志：
　　　　redo log通常是物理日志，記錄的是數(shù)據(jù)頁的物理修改，而不是某一行或某幾行修改成怎樣怎樣，它用來恢復提交后的物理數(shù)據(jù)頁(恢復數(shù)據(jù)頁，且只能恢復到最后一次提交的位置)。
　　　　undo用來回滾行記錄到某個版本。undo log一般是邏輯日志，根據(jù)每行記錄進行記錄。

　　為了高可用的保證，有了多主或者主從切換。

? ? ? 數(shù)據(jù)庫的高可用架構(gòu)一般在系統(tǒng)的底層，這方面的技術(shù)要求比較高，整個高可用系統(tǒng)大致如下：

?

3.總結(jié)

　　我們都知道，單點是系統(tǒng)高可用的大敵，單點往往是系統(tǒng)高可用最大的風險和敵人，應該盡量在系統(tǒng)設計的過程中避免單點。

方法論上，高可用保證的原則是“集群化”，或者叫“冗余”：只有一個單點，掛了服務會受影響；如果有冗余備份，掛了還有其他backup能夠頂上。冗余的最大難道是一致性即復制技術(shù)，mysql提供了一個思路。

有了冗余之后，還不夠，每次出現(xiàn)故障需要人工介入恢復勢必會增加系統(tǒng)的不可服務實踐。所以，又往往是通過“自動故障轉(zhuǎn)移”來實現(xiàn)系統(tǒng)的高可用。災備的恢復一般通過日志來做，日志的設計也是難點，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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。