MySQL高可用方案

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高可用方案