本博主配置好的Centos6下MySQL5.6高可用方案－PXC集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取碼：3897 下載後，用Vmware workstation 打開即可以正常使用。
對於mysql高可用方案，經常用到的的主要有下面三種：
一、基於主從複製的高可用方案：雙節點主從 + keepalived
一般來說，中小型規模的時候，採用這種架構是最省事的。
兩個節點可以採用簡單的一主一從模式，或者雙主模式，並且放置於同一個VLAN中，在master節點發生故障後，利用keepalived/heartbeat的高可用機制實現快速
切換到slave節點。
在這個方案里，有幾個需要注意的地方：
採用keepalived作為高可用方案時，兩個節點最好都設置成BACKUP模式，避免因為意外情況下（比如腦裂）相互搶佔導致往兩個節點寫入相同數據而引發衝突；
1）把兩個節點的auto_increment_increment（自增步長）和auto_increment_offset（自增起始值）設成不同值。其目的是為了避免master節點意外宕機時，
可能會有部分binlog未能及時複製到slave上被應用，從而會導致slave新寫入數據的自增值和原先master上衝突了，因此一開始就使其錯開；當然了，如果有合適的
容錯機制能解決主從自增ID衝突的話，也可以不這麼做；
2）slave節點伺服器配置不要太差，否則更容易導致複製延遲。作為熱備節點的slave伺服器，硬體配置不能低於master節點；
3）如果對延遲問題很敏感的話，可考慮使用MariaDB分支版本，或者直接上線MySQL 5.7最新版本，利用多線程複製的方式可以很大程度降低複製延遲；
4）對複製延遲特別敏感的另一個備選方案，是採用semi sync replication（就是所謂的半同步複製）或者後面會提到的PXC方案，基本上無延遲，不過事務並發性
能會有不小程度的損失，需要綜合評估再決定；
5）keepalived的檢測機制需要適當完善，不能僅僅只是檢查mysqld進程是否存活，或者MySQL服務埠是否可通，還應該進一步做數據寫入或者運算的探測，判斷響
應時間，如果超過設定的閾值，就可以啟動切換機制；
6）keepalived最終確定進行切換時，還需要判斷slave的延遲程度。需要事先定好規則，以便決定在延遲情況下，採取直接切換或等待何種策略。直接切換可能因為復
制延遲有些數據無法查詢到而重複寫入；
7）keepalived或heartbeat自身都無法解決腦裂的問題，因此在進行服務異常判斷時，可以調整判斷腳本，通過對第三方節點補充檢測來決定是否進行切換，可降低腦
裂問題產生的風險。
雙節點主從+keepalived/heartbeat方案架構示意圖見下：
二、基於主從複製的高可用方案：多節點主從+MHA/MMM
多節點主從，可以採用一主多從，或者雙主多從的模式。
這種模式下，可以採用MHA或MMM來管理整個集群，目前MHA應用的最多，優先推薦MHA，最新的MHA也已支持MySQL 5.6的GTID模式了，是個好消息。
MHA的優勢很明顯：
1）開源，用Perl開發，代碼結構清晰，二次開發容易；
2）方案成熟，故障切換時，MHA會做到較嚴格的判斷，盡量減少數據丟失，保證數據一致性；
3)提供一個通用框架，可根據自己的情況做自定義開發，尤其是判斷和切換操作步驟；
4)支持binlog server，可提高binlog傳送效率，進一步減少數據丟失風險。
不過MHA也有些限制：
1）需要在各個節點間打通ssh信任，這對某些公司安全制度來說是個挑戰，因為如果某個節點被黑客攻破的話，其他節點也會跟著遭殃；
2）自帶提供的腳本還需要進一步補充完善，當然了，一般的使用還是夠用的。
三、基於Galera協議的高可用方案：PXC
本博主配置好的Centos6下MySQL5.6高可用方案－PXC集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取碼：3897 下載後，用Vmware workstation 打開即可以正常使用
Galera是Codership提供的多主數據同步複製機制，可以實現多個節點間的數據同步複製以及讀寫，並且可保障資料庫的服務高可用及數據一致性。
基於Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（簡稱PXC），目前PXC用的會比較多一些。
mariadb的集群原理跟PXC一樣,maridb-cluster其實就是PXC，兩者原理是一樣的。
下面重點介紹下基於PXC的mysql高可用環境部署記錄。
1、PXC介紹
Percona XtraDB Cluster（簡稱PXC集群）提供了MySQL高可用的一種實現方法。
1）集群是有節點組成的，推薦配置至少3個節點，但是也可以運行在2個節點上。
2）每個節點都是普通的mysql/percona伺服器，可以將現有的資料庫伺服器組成集群，反之，也可以將集群拆分成單獨的伺服器。
3）每個節點都包含完整的數據副本。
PXC集群主要由兩部分組成：Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一個通用的用於事務型應用的同步、多主複製插件）。
2、PXC特性
1）同步複製，事務要麼在所有節點提交或不提交。
2）多主複製，可以在任意節點進行寫操作。
3）在從伺服器上並行應用事件，真正意義上的並行複製。
4）節點自動配置，數據一致性，不再是非同步複製。
PXC最大的優勢：強一致性、無同步延遲
3、PXC優缺點
PXC的優點
1）服務高可用；
2）數據同步複製(並發複製)，幾乎無延遲；
3）多個可同時讀寫節點，可實現寫擴展，不過最好事先進行分庫分表，讓各個節點分別寫不同的表或者庫，避免讓galera解決數據衝突；
4）新節點可以自動部署，部署操作簡單；
5）數據嚴格一致性，尤其適合電商類應用；
6）完全兼容MySQL；
雖然PXC有這麼多好處，但也有些局限性：
1）只支持InnoDB引擎；當前版本（5.6.20）的複製只支持InnoDB引擎，其他存儲引擎的更改不複製。然而，DDL（Data Definition Language） 語句在statement級別
被複制，並且，對mysql.*表的更改會基於此被複制。例如CREATE USER…語句會被複制，但是 INSERT INTO mysql.user…語句則不會。
（也可以通過wsrep_replicate_myisam參數開啟myisam引擎的複製，但這是一個實驗性的參數）。
2）PXC集群一致性控制機制，事有可能被終止，原因如下：集群允許在兩個節點上同時執行操作同一行的兩個事務，但是只有一個能執行成功，另一個會被終止，集群會給被終止的
客戶端返回死鎖錯誤(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
3）寫入效率取決於節點中最弱的一台，因為PXC集群採用的是強一致性原則，一個更改操作在所有節點都成功才算執行成功。
4）所有表都要有主鍵；
5）不支持LOCK TABLE等顯式鎖操作；
6）鎖衝突、死鎖問題相對更多；
7）不支持XA；
8）集群吞吐量/性能取決於短板；
9）新加入節點採用SST時代價高；
10）存在寫擴大問題；
11）如果並發事務量很大的話，建議採用InfiniBand網路，降低網路延遲；
事實上，採用PXC的主要目的是解決數據的一致性問題，高可用是順帶實現的。因為PXC存在寫擴大以及短板效應，並發效率會有較大損失，類似semi sync replication機制。
本博主配置好的Centos6下MySQL5.6高可用方案－PXC集群環境虛擬機下載，鏈接：https://pan.baidu.com/s/1fuTXUNMpULlSHiriw2xKEg
提取碼：3897 下載後，用Vmware workstation 打開即可以正常使用
以下文章點擊率最高
Loading…