MySQL高可用方案
生產環境中最常見的就是基於主從復制的方案，其次是基於Galera的方案
其次看對數據一致性的要求
對數據一致性要求較高的建議是基於Galera的PXC
盡可能減少數據丟失的建議MHA
允許丟一些數據的可以使用mysql + keepalived
基於主從復制的高可用方案
雙節點主從 + keepalived
一般來說，中小型規模的時候，采用這種架構是最省事的。
兩個節點可以采用簡單的一主一從模式，或者雙主模式，並且放置於同一個VLAN中，在master節點發生故障后，利用keepalived的高可用機制實現快速切換到slave節點
在這個方案里，有幾個需要注意的地方：
* 采用keepalived作為高可用方案時，兩個節點最好都設置成BACKUP模式，避免因為意外情況下（比如腦裂）相互搶占導致往兩個節點寫入相同數據而引發沖突；
* slave節點服務器配置不要太差，否則更容易導致復制延遲。作為熱備節點的slave服務器，硬件配置不能低於master節點；
* 如果對延遲問題很敏感的話，利用多線程復制的方式可以很大程度降低復制延遲；
* keepalived的檢測機制需要適當完善，不能僅僅只是檢查mysqld進程是否存活，或者MySQL服務端口是否可通，還應該進一步做數據寫入或者運算的探測，判斷響應時間，如果超過設定的閾值，就可以啟動切換機制；
* keepalived最終確定進行切換時，還需要判斷slave的延遲程度。需要事先定好規則，以便決定在延遲情況下，采取直接切換或等待何種策略。直接切換可能因為復制延遲有些數據無法查詢到而重復寫入；
* keepalived自身無法解決腦裂的問題，因此在進行服務異常判斷時，可以調整判斷腳本，通過對第三方節點補充檢測來決定是否進行切換，可降低腦裂問題產生的風險。
MHA高可用方案
原理
（1）從宕機崩潰的master保存二進制日志事件（binlog events）;
（2）識別含有最新更新的slave；
（3）應用差異的中繼日志（relay log）到其他的slave；
（4）應用從master保存的二進制日志事件（binlog events）；
（5）提升一個slave為新的master；
（6）使其他的slave連接新的master進行復制；
MHA的優勢很明顯：
方案成熟，故障切換時，MHA會做到較嚴格的判斷，盡量減少數據丟失，保證數據一致性；
提供一個通用框架，可根據自己的情況做自定義開發，尤其是判斷和切換操作步驟；
支持binlog server，可提高binlog傳送效率，進一步減少數據丟失風險。
不過MHA也有些限制：
需要在各個節點間打通ssh信任，這對某些公司安全制度來說是個挑戰，因為如果某個節點被攻破的話，其他節點也會跟着遭殃；
自帶提供的腳本還需要進一步補充完善，當然了，一般的使用還是夠用的。
基於Galera協議的高可用方案
Galera是Codership提供的多主數據同步復制機制，可以實現多個節點間的數據同步復制以及讀寫，並且可保障數據庫的服務高可用及數據一致性。
基於Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（簡稱PXC），目前PXC用的會比較多一些。
PXC的優點
服務高可用；
數據同步復制(並發復制)，幾乎無延遲；
多個可同時讀寫節點，可實現寫擴展，不過最好事先進行分庫分表，讓各個節點分別寫不同的表或者庫，避免讓galera解決數據沖突；
新節點可以自動部署，部署操作簡單；
數據嚴格一致性，尤其適合電商類應用；
完全兼容MySQL；
雖然有這么多好處，但也有些局限性：
只支持InnoDB引擎；
所有表都要有主鍵；
不支持LOCK TABLE等顯式鎖操作；
鎖沖突、死鎖問題相對更多；
不支持XA；
集群吞吐量/性能取決於短板；
新加入節點采用SST時代價高；
存在寫擴大問題；
如果並發事務量很大的話，建議采用InfiniBand網絡，降低網絡延遲；
事實上，采用PXC的主要目的是解決數據的一致性問題，高可用是順帶實現的。因為PXC存在寫擴大以及短板效應，並發效率會有較大損失，類似semi sync replication機制。
容忍少量的數據丟失以及成本的問題的角度上建議 keepalived+mysql高可用方案