高可用HA（High Availability）是分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。
假設系統一直能夠提供服務，我們說系統的可用性是100%。如果系統每運行100個時間單位，會有1個時間單位無法提供服務，我們說系統的可用性是99%。很多公司的高可用目標是4個9，也就是99.99%，這就意味著，系統的年停機時間為8.76個小時。
百度的搜索首頁，是業內公認高可用保障非常出色的系統，甚至人們會通過www.baidu.com 能不能訪問來判斷“網絡的連通性”，百度高可用的服務讓人留下啦“網絡通暢，百度就能訪問”，“百度打不開，應該是網絡連不上”的印象，這其實是對百度HA最高的褒獎。
1. MySQL高可用
說到MySQL的高可用，不得不提到復制，復制是MySQL高可用的基礎。復制解決了什么問題呢？
- 實現數據備份
- 如果有從服務器，主服務器發生故障之后，開通從服務器的寫入功能，從而提供高可用的使用功能
- 異地容災
- 分攤負載（scale out ）主服務器：寫、從服務器：讀
1.1 主從復制流程
不同的復制協議：
1.2 高可用復制架構
1.3.mysql 高可用架構
1.3.1 MySQL Cluster架構
限制存儲引擎為NDB存儲引擎：
1.3.2 MySQL+MMM架構
MMM即Master-Master Replication Manager for MySQL（mysql主主復制管理器），是關于mysql主主復制配置的監控、故障轉移和管理的一套可伸縮的腳本套件（在任何時候只有一個節點可以被寫入），這個套件也能基于標準的主從配置的任意數量的從服務器進行讀負載均衡，所以你可以用它來在一組居于復制的服務器啟動虛擬ip，除此之外，它還有實現數據備份、節點之間重新同步功能的腳本。
MySQL本身沒有提供replication failover的解決方案，通過MMM方案能實現服務器的故障轉移，從而實現mysql的高可用。
此方案特點：
1、安全、穩定性較高，可擴展性好
2、 對服務器數量要求至少三臺及以上
3、 對雙主（主從復制性要求較高）
4、 同樣可實現讀寫分離
1.3.3 MySQL+MHA架構
MHA目前在MySQL高可用方案中應該也是比較成熟和常見的方案，它由日本人開發出來，在MySQL故障切換過程中，MHA能做到快速自動切換操作，而且還能最大限度保持數據的一致性。
此架構特點：
1、安裝布署簡單，不影響現有架構
2、自動監控和故障轉移
3、保障數據一致性
4、故障切換方式可使用手動或自動多向選擇
5、適應范圍大（適用任何存儲引擎）
2.MySQL高可用帶給我們對高可用架構設計的思考
為了保證數據的一致性，MySQL提出了復制的概念。
為了滿足acid，MySQL提供了兩種日志redo和undo日志，redo log是重做日志，提供前滾操作，undo log是回滾日志，提供回滾操作。undo log不是redo log的逆向過程，其實它們都算是用來恢復的日志：redo log通常是物理日志，記錄的是數據頁的物理修改，而不是某一行或某幾行修改成怎樣怎樣，它用來恢復提交后的物理數據頁(恢復數據頁，且只能恢復到最后一次提交的位置)。undo用來回滾行記錄到某個版本。undo log一般是邏輯日志，根據每行記錄進行記錄。為了高可用的保證，有了多主或者主從切換。
數據庫的高可用架構一般在系統的底層，這方面的技術要求比較高，整個高可用系統大致如下：
3.總結
我們都知道，單點是系統高可用的大敵，單點往往是系統高可用最大的風險和敵人，應該盡量在系統設計的過程中避免單點。
方法論上，高可用保證的原則是“集群化”，或者叫“冗余”：只有一個單點，掛了服務會受影響；如果有冗余備份，掛了還有其他backup能夠頂上。冗余的最大難道是一致性即復制技術，MySQL提供了一個思路。
有了冗余之后，還不夠，每次出現故障需要人工介入恢復勢必會增加系統的不可服務實踐。所以，又往往是通過“自動故障轉移”來實現系統的高可用。災備的恢復一般通過日志來做，日志的設計也是難點，MySQL提供了一個思路。
