高可用HA(High Availability)是分佈式系統架構設計中必須考慮的因素之一,它一般是指,經過設計減小系統不能提供服務的時間。html
假設系統一直可以提供服務,咱們說系統的可用性是100%。若是系統每運行100個時間單位,會有1個時間單位沒法提供服務,咱們說系統的可用性是99%。不少公司的高可用目標是4個9,也就是99.99%,這就意味着,系統的年停機時間爲8.76個小時。mysql
百度的搜索首頁,是業內公認高可用保障很是出色的系統,甚至人們會經過www.baidu.com 能不能訪問來判斷「網絡的連通性」,百度高可用的服務讓人留下啦「網絡通暢,百度就能訪問」,「百度打不開,應該是網絡連不上」的印象,這實際上是對百度HA最高的褒獎。sql
說到mysql的高可用,不得不提到複製,複製是 mysql高可用的基礎。複製解決了什麼問題呢?數據庫
實現數據備份安全
若是有從服務器,主服務器發生故障以後,開通從服務器的寫入功能,從而提供高可用的使用功能服務器
異地容災網絡
分攤負載(scale out )主服務器:寫 從服務器:讀架構
1.1 主從複製流程oracle
不一樣的複製協議負載均衡
1.2.高可用複製架構
1.3.mysql 高可用架構
1.3.1 MySQL Cluster架構
1.3.2 MySQL+MMM架構
MMM即Master-Master Replication Manager for MySQL(mysql主主複製管理器),是關於mysql主主複製配置的監控、故障轉移和管理的一套可伸縮的腳本套件(在任什麼時候候只有一個節點能夠被寫入),這個套件也能基於標準的主從配置的任意數量的從服務器進行讀負載均衡,因此你能夠用它來在一組居於複製的服務器啓動虛擬ip,除此以外,它還有實現數據備份、節點之間從新同步功能的腳本。
MySQL自己沒有提供replication failover的解決方案,經過MMM方案能實現服務器的故障轉移,從而實現mysql的高可用。
此方案特色:
一、安全、穩定性較高,可擴展性好
二、 對服務器數量要求至少三臺及以上
三、 對雙主(主從複製性要求較高)
四、 一樣可實現讀寫分離
1.3.3 MySQL+MHA架構
MHA目前在Mysql高可用方案中應該也是比較成熟和常見的方案,它由日本人開發出來,在mysql故障切換過程當中,MHA能作到快速自動切換操做,並且還能最大限度保持數據的一致性
此架構特色:
一、安裝佈署簡單,不影響現有架構
二、自動監控和故障轉移
三、保障數據一致性
四、故障切換方式可以使用手動或自動多向選擇
五、適應範圍大(適用任何存儲引擎)
爲了保證數據的一致性,mysql提出了複製的概念。
爲了知足acid,mysql提供了兩種日誌redo和undo日誌,
redo log是重作日誌,提供前滾操做,undo log是回滾日誌,提供回滾操做。
undo log不是redo log的逆向過程,其實它們都算是用來恢復的日誌:
redo log一般是物理日誌,記錄的是數據頁的物理修改,而不是某一行或某幾行修改爲怎樣怎樣,它用來恢復提交後的物理數據頁(恢復數據頁,且只能恢復到最後一次提交的位置)。
undo用來回滾行記錄到某個版本。undo log通常是邏輯日誌,根據每行記錄進行記錄。
爲了高可用的保證,有了多主或者主從切換。
數據庫的高可用架構通常在系統的底層,這方面的技術要求比較高,整個高可用系統大體以下:
咱們都知道,單點是系統高可用的大敵,單點每每是系統高可用最大的風險和敵人,應該儘可能在系統設計的過程當中避免單點。
方法論上,高可用保證的原則是「集羣化」,或者叫「冗餘」:只有一個單點,掛了服務會受影響;若是有冗餘備份,掛了還有其餘backup可以頂上。 冗餘的最大難道是一致性即複製技術,mysql提供了一個思路。
有了冗餘以後,還不夠,每次出現故障須要人工介入恢復勢必會增長系統的不可服務實踐。因此,又每每是經過「自動故障轉移」來實現系統的高可用。 災備的恢復通常經過日誌來作,日誌的設計也是難點,mysql提供了一個思路。
【1】 http://uat.severalnines.com/blog/comparing-replication-solutions-oracle-and-mysql
【2】 https://mysqlhighavailability.com/mysql-group-replication-hello-world/
【3】 http://www.javashuo.com/article/p-ywubhsun-bs.html
【4】 http://www.sohu.com/a/197271694_505827
【5】 https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.html