可選MySQL高可用方案

　　MySQL的各種高可用方案，大多是基于以下幾種基礎(chǔ)來部署的：

　　基于主從復(fù)制;

　　基于Galera協(xié)議;

　　基于NDB引擎;

　　基于中間件/proxy;

　　基于共享存儲;

　　基于主機高可用;

　　在這些可選項中，最常見的就是基于主從復(fù)制的方案，其次是基于Galera的方案，我們重點說說這兩種方案。其余幾種方案在生產(chǎn)上用的并不多，我們只簡單說下。

　　基于主從復(fù)制的高可用方案

　　雙節(jié)點主從 + keepalived/heartbeat

　　一般來說，中小型規(guī)模的時候，采用這種架構(gòu)是最省事的。

　　兩個節(jié)點可以采用簡單的一主一從模式，或者雙主模式，并且放置于同一個VLAN中，在master節(jié)點發(fā)生故障后，利用keepalived/heartbeat的高可用機制實現(xiàn)快速切換到slave節(jié)點。

　　在這個方案里，有幾個需要注意的地方：

　　采用keepalived作為高可用方案時，兩個節(jié)點***都設(shè)置成BACKUP模式，避免因為意外情況下(比如腦裂)相互搶占導(dǎo)致往兩個節(jié)點寫入相同數(shù)據(jù)而引發(fā)沖突;

　　把兩個節(jié)點的auto_increment_increment(自增起始值)和auto_increment_offset(自增步長)設(shè)成不同值。其目的是為了避免master節(jié)點意外宕機時，可能會有部分binlog未能及時復(fù)制到slave上被應(yīng)用，從而會導(dǎo)致slave新寫入數(shù)據(jù)的自增值和原先master上沖突了，因此一開始就使其錯開;當(dāng)然了，如果有合適的容錯機制能解決主從自增ID沖突的話，也可以不這么做;

　　slave節(jié)點服務(wù)器配置不要太差，否則更容易導(dǎo)致復(fù)制延遲。作為熱備節(jié)點的slave服務(wù)器，硬件配置不能低于master節(jié)點;

　　如果對延遲問題很敏感的話，可考慮使用MariaDB分支版本，或者直接上線MySQL 5.7***版本，利用多線程復(fù)制的方式可以很大程度降低復(fù)制延遲;

　　對復(fù)制延遲特別敏感的另一個備選方案，是采用semi sync replication(就是所謂的半同步復(fù)制)或者后面會提到的PXC方案，基本上無延遲，不過事務(wù)并發(fā)性能會有不小程度的損失，需要綜合評估再決定;

　　keepalived的檢測機制需要適當(dāng)完善，不能僅僅只是檢查mysqld進(jìn)程是否存活，或者M(jìn)ySQL服務(wù)端口是否可通，還應(yīng)該進(jìn)一步做數(shù)據(jù)寫入或者運算的探測，判斷響應(yīng)時間，如果超過設(shè)定的閾值，就可以啟動切換機制;

　　keepalived最終確定進(jìn)行切換時，還需要判斷slave的延遲程度。需要事先定好規(guī)則，以便決定在延遲情況下，采取直接切換或等待何種策略。直接切換可能因為復(fù)制延遲有些數(shù)據(jù)無法查詢到而重復(fù)寫入;

　　keepalived或heartbeat自身都無法解決腦裂的問題，因此在進(jìn)行服務(wù)異常判斷時，可以調(diào)整判斷腳本，通過對第三方節(jié)點補充檢測來決定是否進(jìn)行切換，可降低腦裂問題產(chǎn)生的風(fēng)險。

　　雙節(jié)點主從+keepalived/heartbeat方案架構(gòu)示意圖見下：

　　圖解：MySQL雙節(jié)點(單向/雙向主從復(fù)制)，采用keepalived實現(xiàn)高可用架構(gòu)。

　　多節(jié)點主從+MHA/MMM

　　多節(jié)點主從，可以采用一主多從，或者雙主多從的模式。

　　這種模式下，可以采用MHA或MMM來管理整個集群，目前MHA應(yīng)用的最多，優(yōu)先推薦MHA，***的MHA也已支持MySQL 5.6的GTID模式了，是個好消息。

　　MHA的優(yōu)勢很明顯：

　　開源，用Perl開發(fā)，代碼結(jié)構(gòu)清晰，二次開發(fā)容易;

　　方案成熟，故障切換時，MHA會做到較嚴(yán)格的判斷，盡量減少數(shù)據(jù)丟失，保證數(shù)據(jù)一致性;

　　提供一個通用框架，可根據(jù)自己的情況做自定義開發(fā)，尤其是判斷和切換操作步驟;

　　支持binlog server，可提高binlog傳送效率，進(jìn)一步減少數(shù)據(jù)丟失風(fēng)險。

　　不過MHA也有些限制：

　　需要在各個節(jié)點間打通ssh信任，這對某些公司安全制度來說是個挑戰(zhàn)，因為如果某個節(jié)點被黑客攻破的話，其他節(jié)點也會跟著遭殃;

　　自帶提供的腳本還需要進(jìn)一步補充完善，當(dāng)然了，一般的使用還是夠用的。

　　多節(jié)點主從+etcd/zookeeper

　　在大規(guī)模節(jié)點環(huán)境下，采用keepalived或者M(jìn)HA作為MySQL的高可用管理還是有些復(fù)雜或麻煩。

　　首先，這么多節(jié)點如果沒有采用配置服務(wù)來管理，必然雜亂無章，線上切換時很容易誤操作。

　　在較大規(guī)模環(huán)境下，建議采用etcd/zookeeper管理集群，可實現(xiàn)快速檢測切換，以及便捷的節(jié)點管理。

　　基于Galera協(xié)議的高可用方案

　　Galera是Codership提供的多主數(shù)據(jù)同步復(fù)制機制，可以實現(xiàn)多個節(jié)點間的數(shù)據(jù)同步復(fù)制以及讀寫，并且可保障數(shù)據(jù)庫的服務(wù)高可用及數(shù)據(jù)一致性。

　　基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster(簡稱PXC)，目前PXC用的會比較多一些。

　　PXC的架構(gòu)示意圖見下：

　　(圖片源自網(wǎng)絡(luò))，圖解：在底層采用wsrep接口實現(xiàn)數(shù)據(jù)在多節(jié)點間的同步復(fù)制。

　　(圖片源自網(wǎng)絡(luò))，圖解：在PXC中，一次數(shù)據(jù)寫入在各個節(jié)點間的驗證/回滾流程。

　　PXC的優(yōu)點

　　服務(wù)高可用;

　　數(shù)據(jù)同步復(fù)制(并發(fā)復(fù)制)，幾乎無延遲;

　　多個可同時讀寫節(jié)點，可實現(xiàn)寫擴展，不過***事先進(jìn)行分庫分表，讓各個節(jié)點分別寫不同的表或者庫，避免讓galera解決數(shù)據(jù)沖突;

　　新節(jié)點可以自動部署，部署操作簡單;

　　數(shù)據(jù)嚴(yán)格一致性，尤其適合電商類應(yīng)用;

　　完全兼容MySQL;

　　雖然有這么多好處，但也有些局限性：

　　只支持InnoDB引擎;

　　所有表都要有主鍵;

　　不支持LOCK TABLE等顯式鎖操作;

　　鎖沖突、死鎖問題相對更多;

　　不支持XA;

　　集群吞吐量/性能取決于短板;

　　新加入節(jié)點采用SST時代價高;

　　存在寫擴大問題;

　　如果并發(fā)事務(wù)量很大的話，建議采用InfiniBand網(wǎng)絡(luò)，降低網(wǎng)絡(luò)延遲;

　　事實上，采用PXC的主要目的是解決數(shù)據(jù)的一致性問題，高可用是順帶實現(xiàn)的。因為PXC存在寫擴大以及短板效應(yīng)，并發(fā)效率會有較大損失，類似semi sync replication機制。

　　其他高可用方案

　　基于NDB Cluster，由于NDB目前仍有不少缺陷和限制，不建議在生產(chǎn)環(huán)境上使用;

　　基于共享存儲，一方面需要不太差的存儲設(shè)備，另外共享存儲可也會成為新的單點，除非采用基于高速網(wǎng)絡(luò)的分布式存儲，類似RDS的應(yīng)用場景，架構(gòu)方案就更復(fù)雜了，成本也可能更高;

　　基于中間件(Proxy)，現(xiàn)在可靠的Proxy選擇并不多，而且沒有通用的Proxy，都有有所針對，比如有的專注解決讀寫分離，有的專注分庫分表等等，真正好用的Proxy一般要自行開發(fā);

　　基于主機高可用，是指采用類似RHCS構(gòu)建一個高可用集群后，再部署MySQL應(yīng)用的方案。老實說，我沒實際用過，但從側(cè)面了解到這種方案生產(chǎn)上用的并不多，可能也有些局限性所致吧;

　　以DBA們的聰明才智，肯定還有其他我不知道的方案，也歡迎同行們間多多交流。