之前梳理了Mysql+Keepalived雙主熱備高可用操作記錄，對於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
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機制。
4、PXC原理描述
分布式系統的CAP理論： C：一致性，所有的節點數據一致 A：可用性，一個或者多個節點失效，不影響服務請求 P：分區容忍性，節點間的連接失效，仍然可以處理請求 其實，任何一個分布式系統，需要滿足這三個中的兩個。 PXC會使用大概是4個端口號 3306：數據庫對外服務的端口號 4444：請求SST SST: 指數據一個鏡象傳輸 xtrabackup , rsync ,mysqldump 4567: 組成員之間進行溝通的一個端口號 4568: 傳輸IST用的。相對於SST來說的一個增量。 一些名詞介紹： WS：write set 寫數據集 IST: Incremental State Transfer 增量同步 SST：State Snapshot Transfer 全量同步 PXC環境所涉及的端口： #mysql實例端口 10Regular MySQL port, default 3306. #pxc cluster相互通訊的端口 2）Port for group communication, default 4567. It can be changed by the option: wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4010; " #用於SST傳送的端口 3）Port for State Transfer, default 4444. It can be changed by the option: wsrep_sst_receive_address=10.11.12.205:5555 #用於IST傳送的端口 4）Port for Incremental State Transfer, default port for group communication + 1 (4568). It can be changed by the option: wsrep_provider_options = "ist.recv_addr=10.11.12.206:7777; "
PXC的架構示意圖：
數據讀寫示意圖
---------------------------------------下面看下傳統復制流程----------------------------------
異步復制
半同步 超過10秒的閥值會退化為異步
不管同步或是半同步，都存在一定的延遲，那么PXC怎么做到不延遲呢？
PXC最大的優勢：強一致性、無同步延遲
每一個節點都可以讀寫，WriteSet寫的集合，用箱子推給Group里所有的成員， data page 相當於物理復制，而不是發日志，就是一個寫的結果了。
PXC原理圖
從上圖可以看出： 當client端執行dml操作時，將操作發給server，server的native進程處理請求，client端執行commit，server將復制寫數據集發給group(cluster)，cluster 中每個動作對應一個GTID，其它server接收到並通過驗證(合並數據)后，執行appyl_cb動作和commit_cb動作，若驗證沒通過，則會退出處理;當前server節點驗證通 過后，執行commit_cb，並返回，若沒通過，執行rollback_cb。 只要當前節點執行了commit_cb和其它節點驗證通過后就可返回。 3306:數據庫對外服務的端口號 4444:請求SST，在新節點加入時起作用 4567:組成員之間溝通的端口 4568:傳輸IST，節點下線，重啟加入時起作用 SST:全量同步 IST:增量同步 問題：如果主節點寫入過大，apply_cb時間跟不上，怎么處理？ Wsrep_slave_threads參數配置成cpu的個數相等或是1.5倍。
用戶發起Commit，在收到Ok之前，集群每次發起一個動作，都會有一個唯一的編號 ，也就是PXC獨有的Global Trx Id。
動作發起者是commit_cb，其它節點多了一個動作： apply_cb
上面的這些動作，是通過那個端號交互的？
4567，4568端口，IST只是在節點下線，重啟加入那一個時間有用
4444端口，只會在新節點加入進來時起作用
PXC結構里面，如果主節點寫入過大，apply_cb 時間會不會跟不上，那么wsrep_slave_threads參數 解決apply_cb跟不上問題 配置成和CPU的個數相等或是1.5倍
當前節點commit_cb 后就可以返回了，推過去之后，驗證通過就行了可以返回客戶端了，cb也就是commit block 提交數據塊.
5、PXC啟動和關閉過程
State Snapshot Transfer(SST)，每個節點都有一份獨立的數據，當用mysql bootstrap-pxc啟動第一個節點，在第一個節點上把帳號初始化，其它節點啟動后加入進來。集群中有哪些節點是由wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx參數決定。第一個節點把自己備份一下(snapshot)傳給加入的新節點，第三個節點的死活是由前兩個節點投票決定。
狀態機變化階段： 1）OPEN: 節點啟動成功，嘗試連接到集群，如果失敗則根據配置退出或創建新的集群 2）PRIMARY: 節點處於集群PC中，嘗試從集群中選取donor進行數據同步 3）JOINER: 節點處於等待接收/接收數據文件狀態，數據傳輸完成后在本地加載數據 4）JOINED: 節點完成數據同步工作，嘗試保持和集群進度一致 5）SYNCED：節點正常提供服務：數據的讀寫，集群數據的同步，新加入節點的sst請求 6）DONOR(貢獻數據者)：節點處於為新節點准備或傳輸集群全量數據狀態，對客戶端不可用。 狀態機變化因素： 1）新節點加入集群 2）節點故障恢復 3）節點同步失效 傳輸SST有幾種方法: 1）mysqldump 2）xtrabackup 3）rsync 比如有三個節點：node1、node2、node3 當node3停機重啟后，通過IST來同步增量數據，來完成保證與node1和node2的數據一致，IST的實現是由wsrep_provider_options="gcache.size=1G"參數決定， 一般設置為1G大，參數大小是由什么決定的，根據停機時間，若停機一小時，需要確認1小時內產生多大的binlog來算出參數大小。 假設這三個節點都關閉了，會發生什么呢？ 全部傳SST，因為gcache數據沒了 全部關閉需要采用滾動關閉方式： 1）關閉node1，修復完后，啟動加回來; 2）關閉node2,修復完后，啟動加回來; 3）......,直到最后一個節點 4）原則要保持Group里最少一個成員活着 數據庫關閉之后，最會保存一個last Txid，所以啟動時，先要啟動最后一個關閉的節點，啟動順序和關閉順序剛好相反。 wsrep_recover=on參數在啟動時加入，用於從log中分析gtid。 怎樣避免關閉和啟動時數據丟失？ 1）所有的節點中最少有一個在線，進行滾動重啟; 2）利用主從的概念，把一個從節點轉化成PXC里的節點。
6、PXC注意的問題
1）腦裂：任何命令執行出現unkown command ，表示出現腦裂，集群兩節點間4567端口連不通，無法提供對外服務。 SET GLOBAL wsrep_provider_options="pc.ignore_sb=true"; 2）並發寫：三個節點的自增起始值為1、2、3，步長都為3，解決了insert問題，但update同時對一行操作就會有問題，出現： Error： 1213 SQLSTATE: 40001，所以更新和寫入在一個節點上操作。 3）DDL：引起全局鎖，采用：pt-online-schema-change 4）MyISAM引擎不能被復制，只支持innodb 5）pxc結構里面必須有主鍵，如果沒有主建，有可能會造成集中每個節點的Data page里的數據不一樣 6）不支持表級鎖，不支持lock /unlock tables 7）pxc里只能把slow log ,query log 放到File里 8）不支持XA事務 9）性能由集群中性能最差的節點決定
------------------------------------------------------------------------------------------------------------
下面記錄在Centos下部署基於PXC的Mysql高可用方案操作過程
官方配置說明：https://www.percona.com/doc/percona-xtradb-cluster/5.5/howtos/centos_howto.html
1）環境描述（centos6.8版本）
node1 10.171.60.171 percona1
node2 10.44.183.73 percona2
node3 10.51.58.169 percona3
三個節點上的iptables最好關閉（否則就要開放3306、4444、4567、4568端口的訪問）、關閉selinux
2）三個node節點都要執行以下操作。
可以選擇源碼或者yum，在此使用yum安裝。
基礎安裝
[root@percona1 ~]# yum -y groupinstall Base Compatibility libraries Debugging Tools Dial-up Networking suppport Hardware monitoring utilities Performance Tools Development tools
組件安裝
[root@percona1 ~]# yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm -y
[root@percona1 ~]# yum install Percona-XtraDB-Cluster-55 -y
3）數據庫配置
選擇一個node作為名義上的master，下面就以node1為master，只需要修改mysql的配置文件－－/etc/my.cnf
－－－－－－－－－－－－－－－－以下是在node1節點上的配置－－－－－－－－－－－－－－－－－－－－－－
[root@percona1 ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
user=mysql
# Path to Galera library
wsrep_provider=/usr/lib64/libgalera_smm.so
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://10.171.60.171,10.44.183.73,10.51.58.169
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #1 address
wsrep_node_address=10.171.60.171
# SST method
wsrep_sst_method=xtrabackup-v2
# Cluster name
wsrep_cluster_name=my_centos_cluster
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
啟動數據庫（三個節點都要操作）：
node1的啟動方式：
[root@percona1 ~]# /etc/init.d/mysql bootstrap-pxc
.....................................................................
如果是centos7，則啟動命令如下：
[root@percona1 ~]# systemctl start mysql@bootstrap.service
.....................................................................
若是重啟的話，就先kill，然后刪除pid文件后再執行上面的啟動命令。
配置數據庫（三個節點都要操作）
mysql> show status like 'wsrep%';
+----------------------------+--------------------------------------+
| Variable_name | Value |
+----------------------------+--------------------------------------+
.........
| wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 0 |
| wsrep_causal_reads | 0 |
| wsrep_incoming_addresses | 10.171.60.171:3306 | //集群中目前只有一個成員的ip
| wsrep_cluster_conf_id | 1 |
| wsrep_cluster_size | 1 | //主要看這里，目前node2和node3還沒有加入集群，所以集群成員目前只有一個
| wsrep_cluster_state_uuid | 5dee8d6d-455f-11e7-afd8-ca25b704d994 |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 0 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 2.12(r318911d) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+----------------------------+--------------------------------------+
數據庫用戶名密碼的設置
mysql> UPDATE mysql.user SET password=PASSWORD("Passw0rd") where user='root';
創建、授權、同步賬號
mysql> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 's3cret';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
mysql> FLUSH PRIVILEGES;
................注意下面幾個察看命令...............
mysql> SHOW VARIABLES LIKE 'wsrep_cluster_address';
#如果配置了指向集群地址，上面那個參數值，應該是你指定集群的IP地址
# 此參數查看是否開啟
mysql> show status like 'wsrep_ready';
# 查看集群的成員數
mysql> show status like 'wsrep_cluster_size';
# 這個查看wsrep的相關參數
mysql> show status like 'wsrep%';
4）那么node2和node3只需要配置my.cnf文件中的wsrep_node_address這個參數，將其修改為自己的ip地址即可。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
node2節點的/etc/my.cnf配置
[root@percona2 ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
user=mysql
# Path to Galera library
wsrep_provider=/usr/lib64/libgalera_smm.so
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://10.171.60.171,10.44.183.73,10.51.58.169
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #1 address
wsrep_node_address=10.44.183.73
# SST method
wsrep_sst_method=xtrabackup-v2
# Cluster name
wsrep_cluster_name=my_centos_cluster
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
node3節點的/etc/my.cnf配置
[root@percona3 ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
user=mysql
# Path to Galera library
wsrep_provider=/usr/lib64/libgalera_smm.so
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://10.171.60.171,10.44.183.73,10.51.58.169
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #1 address
wsrep_node_address=10.51.58.169
# SST method
wsrep_sst_method=xtrabackup-v2
# Cluster name
wsrep_cluster_name=my_centos_cluster
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
node2和node3的啟動方式：
[root@percona2 ~]# /etc/init.d/mysql start
..................................注意................................
-> 除了名義上的master之外，其它的node節點只需要啟動mysql即可。
-> 節點的數據庫的登陸和master節點的用戶名密碼一致，自動同步。所以其它的節點數據庫用戶名密碼無須重新設置。
也就是說，如上設置，只需要在名義上的master節點（如上的node1）上設置權限，其它的節點配置好/etc/my.cnf后，只需要啟動mysql就行，權限會自動同步過來。
如上的node2，node3節點，登陸mysql的權限是和node1一樣的（即是用node1設置的權限登陸）
.....................................................................
如果上面的node2、node3啟動mysql失敗，比如/var/lib/mysql下的err日志報錯如下：
[ERROR] WSREP: gcs/src/gcs_group.cpp:long int gcs_group_handle_join_msg(gcs_
解決辦法：
-> 查看節點上的iptables防火牆是否關閉；檢查到名義上的master節點上的4567端口是否連通（telnet）
-> selinux是否關閉
-> 刪除名義上的master節點上的grastate.dat后，重啟名義上的master節點的數據庫；當然當前節點上的grastate.dat也刪除並重啟數據庫
.....................................................................
5)最后進行測試
在任意一個node上，進行添加，刪除，修改操作，都會同步到其他的服務器，是現在主主的模式，當然前提是表引擎必須是innodb，因為galera目前只支持innodb的表。
mysql> show status like 'wsrep%';
........
wsrep_local_state | 4 |
| wsrep_local_state_comment | Synced |
| wsrep_cert_index_size | 2 |
| wsrep_causal_reads | 0 |
| wsrep_incoming_addresses | 10.44.183.73:3306,10.51.58.169:3306,10.171.60.171:3306 |
| wsrep_cluster_conf_id | 9 |
| wsrep_cluster_size | 3 | //集群成員是3個
| wsrep_cluster_state_uuid | 92e43358-456d-11e7-af61-733b6b73c72c |
| wsrep_cluster_status | Primary |
| wsrep_connected | ON |
| wsrep_local_bf_aborts | 0 |
| wsrep_local_index | 2 |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <info@codership.com> |
| wsrep_provider_version | 2.12(r318911d) |
| wsrep_ready | ON |
| wsrep_thread_count | 2
在node3上創建一個庫
mysql> create database wangshibo;
Query OK, 1 row affected (0.02 sec)
然后在node1和node2上查看，自動同步過來
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
| wangshibo |
+--------------------+
5 rows in set (0.00 sec)
在node1上的wangshibo庫下創建表，插入數據
mysql> use wangshibo;
Database changed
mysql> create table test(
-> id int(5));
Query OK, 0 rows affected (0.11 sec)
mysql> insert into test values(1);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test values(2);
Query OK, 1 row affected (0.02 sec)
同樣，在其它的節點上查看，也是能自動同步過來
mysql> select * from wangshibo.test;
+------+
| id |
+------+
| 1 |
| 2 |
+------+
2 rows in set (0.00 sec)