Mysql高可用架構
低讀低寫並發、低數據量方案
方案一：雙機高可用方案
1.數據庫架構圖
2.特點
一臺機器A作為讀寫庫，另一臺B作為備份庫；A庫故障後B庫作為讀寫庫；A庫恢復後A作為備庫。
3.開發說明
此種情況下，數據源配置中的數據庫IP地址，可采用虛擬的IP地址。虛擬IP地址由兩臺數據庫機器上的keepalive配置，並互相檢測心跳。當其中一臺故障後，虛擬IP地址會自動漂移到另外一臺正常的庫上。
數據庫的主備配置、故障排除和數據補全，需要DBA和運維人員來維護。而程序代碼或配置並不需要修改。
具體配置可參考資料：
http://lizhenliang.blog.51cto.com/7876557/1362313
http://database.51cto.com/art/201012/237204.htm
http://gaoke.iteye.com/blog/2283890
4.適應場景
讀和寫都不高的場景（單表數據低於500萬），雙機高可用。
5.優缺點
優點是一個機器故障了可以自動切換；缺點是只有一個庫在工作，讀寫並未分離，並發有限制。
方案二：主從結構方案
1.數據庫架構圖
2.特點
一臺機器A作為寫庫，另一臺B作為讀庫；A庫故障後B庫充當讀寫，A修復後，B庫為寫庫，A庫為讀庫。
3.開發說明
這種方案的實現，要借助數據庫中間件Mycat來實現，Mycat的datahost配置如下（註意balance和writetype的設置）
<dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
<heartbeat>select user()</heartbeat>
<!--主，用於寫-->
<writeHost host="hostM1" url="192.168.1.135:3306" user="root" password="123" />
<!--主2，用於讀,hostM1 down了，自動切換為主，讀寫都可以-->
<writeHost host="hostM2" url="192.168.1.136:3306" user="root" password="123" />
</dataHost>
項目開發中，要配置Mycat數據源，並實現對Mycat數據源的數據操作。數據庫A和數據庫B應該互為主從。數據庫的主主配置、故障排除和數據補全，依然需要DBA和運維人員來維護。
4.適應場景
讀和寫都不是非常高的場景（單表數據低於1000萬），高可用。比方案一並發要高很多。
5.優缺點
優點是一個機器故障了可以自動切換；讀寫分離，並發有了很大的提升。缺點是引入了一個Mycat節點，若要高可用需要引入至少兩個Mycat。常規的解決方案是引入haproxy和keepalive對mycat做集群。
高讀低寫並發、低數據量方案
方案三：一主多從+讀寫分離
1.數據庫架構圖
2.特點
一個主寫庫A多個從庫，當主庫A故障時，提升從庫B為主寫庫，同時修改C、D庫為B的從庫。A故障修復後，作為B的從庫。
3.開發說明
項目開發中需要使用Mycat作為中間件，來配置主庫和從庫，核心配置如下：
<dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100">
<heartbeat>select user()</heartbeat>
<!--主A，用於寫-->
<writeHost host="hostM1" url="192.168.1.135:3306" user="root" password="123" />
<!—從B，用於讀,hostM1 down了，自動切換為主-->
<writeHost host="hostM2" url="192.168.1.136:3306" user="root" password="123456" />
<!—從C，用於讀-->
<writeHost host="hostM3" url="192.168.1.137:3306" user="root" password="123" />
<!—從D，用於讀-->
<writeHost host="hostM4" url="192.168.1.138:3306" user="root" password="123" />
</dataHost>
主庫A故障後，Mycat會自動把從B提升為寫庫。而C、D從庫，則可以通過MHA等工具，自動修改其主庫為B。進而實現自動切換的目地。
MHA Manager可以單獨部署在一臺獨立的機器上管理多個master-slave集群，也可以部署在一臺slave節點上。MHA Node運行在每臺MySQL服務器上，MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master。整個故障轉移過程對應用程序完全透明。
MHA相關知識請參考：
http://www.cnblogs.com/gomysql/p/3675429.html
4.適應場景
該架構適合寫並發不大、但是讀並發大的很的場景
5.優缺點
由於配置了多個讀節點，讀並發的能力有了質的提高。理論上來說，讀節點可以多個，可以負載很高級別的讀並發。當然，Mycat依然需要設計高可用方案。
高讀寫並發、低數據量方案
方案四：MariaDB Galera Cluster方案
1.數據庫架構圖
2.特點
多個數據庫，在負載均衡作用下，可同時進行寫入和讀取操作；各個庫之間以Galera Replication的方法進行數據同步，即每個庫理論上來說，數據是完全一致的。
3.開發說明
數據庫讀寫時，只需要修改數據庫讀寫IP為keepalive的虛擬節點即可；數據庫配置方面相對比較復雜，需要引入haproxy、keepalive、Galaera等各種插件和配置。
4.適用場景
該方案適合讀寫並發較大、數據量不是非常大的場景。
5.優缺點點
優點：1）可以在任意節點上進行讀2）自動剔除故障節點3）自動加入新節點4）真正並行的復制，基於行級5）客戶端連接跟操作單數據庫的體驗一致。6) 同步復制，因此具有較高的性能和可靠性。
缺點：1) DELETE操作不支持沒有主鍵的表,沒有主鍵的表在不同的節點順序將不同2）處理事務時，會運行一個協調認證程序來保證事務的全局一致性，若該事務長時間運行，就會鎖死節點中所有的相關表，導致插入卡住（這種情況和單表插入是一樣的）。2）整個集群的寫入吞吐量是由最弱的節點限制，如果有一個節點變得緩慢，那麽整個集群將是緩慢的。為了穩定的高性能要求，所有的節點應使用統一的硬件。3）如果DDL語句有問題將破壞集群,建議禁用。4) Mysql數據庫5.7.6及之後的版本才支持此種方案。
高讀寫並發、高數據量方案
方案五 數據庫中間件
1. 數據庫架構圖
2.特點
采用Mycat進行分片存儲，可以解決寫負載均衡和數據量過大問題；每個分片配置多個讀從庫，可以減少單個庫的讀壓力。
3.開發說明
此種情況，需要配置Haproxy、keepalive和mycat集群，每個分片上又需要配置一主多從的集群。每個分片上的完整配置，具體請參考方案三，可以簡單地把方案三理解為一個分片結構。因此，配置和維護量都比較大。
4.適用場景
讀寫並發都很大並且數據量非常大的場景。
5.優缺點
優點：終極的解決高並發高數據量的方法。
缺點：配置和維護都比較麻煩，需要的軟硬件設備資源大。
Mysql高可用架構