這篇文章總結了之前對Galera replication的調研，內容包括Galera特性，原理，Galera cluster配置，參數(shù)及性能等

Galera replication是什么

MySQL DBA及開發(fā)應該都知道MySQL源生復制及semi-sync半同步復制，它們都基于MySQL binlog，原生復制是完全異步的，master不需要保證slave接收并執(zhí)行了binlog，能夠保證master最大性能，但是slave可能存在延遲，主備數(shù)據(jù)無法保證一致性，在不停服務的前提下如果master宕機讓slave頂上，就會丟失數(shù)據(jù)，semi-sync在異步復制基礎上增加了數(shù)據(jù)保護的考慮，master必須確認slave收到binlog后（但不保證slave執(zhí)行了事務）才能最終提交事務，在沒有退化（延遲較大時可能發(fā)生）成異步復制之前可以保證數(shù)據(jù)安全，此時master掛掉之后，slave可以在apply完所有relay log后切換成master提供讀寫服務

Galera replication是 codership 提供的MySQL同步復制方案，它將多個MySQL節(jié)點組織成一個cluster并提供一下特性：
1. 同步復制，主備無延遲
2. 支持多主同時讀寫，保證數(shù)據(jù)一致性
3. 集群中各節(jié)點保存全量數(shù)據(jù)
4. 節(jié)點添加/刪除，自動檢測和配置
5. 行級別并行復制
6. 不需要寫binlog

相對于MySQL源生復制和semi-sync，Galera replication比較有吸引力的特性：
1. 同步復制，主備無延遲，master宕機后slave可以 立即 頂上并提供服務（semi-sync需要apply完所有relay log）
2. 事務沖突檢測保證數(shù)據(jù)一致性，多個節(jié)點可以同時讀寫數(shù)據(jù)，可以極大簡化數(shù)據(jù)訪問

目前可用的產品： MariaDB Galera Cluster 和 Percona XtraDB Cluster

Galera replication原理

Galera replication是一種Certification based replication，保證one-copy serializability，理論基于這兩篇論文 Don’t be lazy, be consistent 和 Database State Machine Approach

算法示意圖(來自上面兩篇論文)

算法偽代碼

事務執(zhí)行協(xié)議

遵守deferred update replication，事務在commit時才復制到其他節(jié)點，執(zhí)行過程分為4個階段：
1．Local read phase
  a) 本地（client連接到的節(jié)點）執(zhí)行事務Ti，但不真正提交，真正提交之前進入Send phase
2．Send phase
  a) 若事務只讀，直接提交，結束（多版本，只讀事務不加鎖）
  b) 將事務的寫操作封裝成WS（Write Set，基于行），廣播到所有節(jié)點（包括自身）
3．Lock / Certificaion phase
  a) 對收到的WS中的每個WSi(X)
    i. 若X沒有被加鎖，對X加鎖
    ii. 若X已被Tj加鎖且Tj處于Local read phase/Send phase，回滾Tj，對X加鎖
    iii. Certification based conflict detect
4．Write phase
  a) 若檢測出沖突，回滾Ti
  b) 否則，執(zhí)行WS，提交事務后釋放鎖資源
  c) 對于源節(jié)點，提交事務并向client返回結果

客戶端/Galera節(jié)點信息交互圖

Galera replication采取的是樂觀策略，即事務在一個節(jié)點提交時，被認為與其他節(jié)點上的事務沒有沖突，首先在本地“執(zhí)行”（之所以帶引號，是因為事務沒有執(zhí)行完）后再發(fā)送到所有節(jié)點做沖突檢測，存在兩種情況下需要回滾事務：
1. WS復制到其它節(jié)點，被加到每個節(jié)點的slave trx queue中，與queue中前面的trxs在做certification test時發(fā)現(xiàn)沖突
2. WS通過了certification test后被保證一定會執(zhí)行，在它執(zhí)行過程中，如果該節(jié)點上有與其沖突的local trxs(Local phase)，回滾local trxs

Galera提供了兩個狀態(tài)參數(shù)記錄沖突：
1. wsrep_local_cert_failures：certification test中未通過的trx數(shù)目
2. wsrep_local_bf_aborts：apply trxs（已經通過certification test）時，回滾的local trxs（open but not commit）數(shù)目

因此事務在commit節(jié)點廣播后， 節(jié)點之間不交換“是否沖突”的信息，各個節(jié)點獨立異步的處理該事務 ，certification based replication協(xié)議保證：
1. 事務在所有節(jié)點上要么都commit，要么都rollback/abort
2. 事務在所有節(jié)點的執(zhí)行順序一致

certification based replication所依賴的基礎技術：
Group Communication System
1) Atomic delivery (事務傳輸要么成功傳給了所有節(jié)點，要么都失敗)
2) Total order (事務在所有節(jié)點中的順序一致)
3) Group maintenance (每個節(jié)點知道所有節(jié)點的狀態(tài))

傳統(tǒng)的2PC（兩階段提交）做法

1. 2PC 事務結束時，所有節(jié)點數(shù)據(jù)達到一致
2. 協(xié)調者與參與者之間通信，參與者之間無連接
3. 受網(wǎng)絡狀態(tài)影響較大
4. 兩次通信，需要得到每個參與者的反饋后才能決定是否提交事務

因此Galera replicateion相對于2PC減少了網(wǎng)絡傳輸次數(shù)，消除了等待節(jié)點返回“決定是否沖突”的時間，從而可以提高了性能

Galera replication原理總結

1. 事務在本地節(jié)點執(zhí)行時采取樂觀策略，成功廣播到所有節(jié)點后再做沖突檢測
2. 檢測出沖突時，本地事務優(yōu)先被回滾
3. 每個節(jié)點獨立、異步執(zhí)行隊列中的WS
4. 事務T在A節(jié)點執(zhí)行成功返回客戶端后，其他節(jié)點保證T一定會被執(zhí)行，因此有可能存在延遲，即虛擬同步

Galera flow control

galera是同步復制（虛擬同步）方案，事務在本地節(jié)點（客戶端提交事務的節(jié)點）上提交成功時，其它節(jié)點保證執(zhí)行該事務。在提交事務時，本地節(jié)點把事務復制到所有節(jié)點后，之后各個節(jié)點獨立異步地進行certification test、事務插入待執(zhí)行隊列、執(zhí)行事務。然而由于不同節(jié)點之間執(zhí)行事務的速度不一樣，長時間運行后，慢節(jié)點的待執(zhí)行隊列可能會越積越長，最終可能導致事務丟失。
galera內部實現(xiàn)了flow control，作用就是協(xié)調各個節(jié)點，保證所有節(jié)點執(zhí)行事務的速度大于隊列增長速度，從而避免丟失事務。實現(xiàn)原理和簡單：整個galera cluster中，同時只有一個節(jié)點可以廣播消息（數(shù)據(jù)），每個節(jié)點都會獲得廣播消息的機會（獲得機會后也可以不廣播），當慢節(jié)點的待執(zhí)行隊列超過一定長度后，它會廣播一個FC_PAUSE消息，所以節(jié)點收到消息后都會暫緩廣播消息，直到該慢節(jié)點的待執(zhí)行隊列長度減小到一定長度后，galera cluster數(shù)據(jù)同步又開始恢復

flow control相關參數(shù)：

gcs.fc_limit：待執(zhí)行隊列長度超過該值時，flow control被觸發(fā)，對于Master-Slave模式(只在一個節(jié)點寫)的galera cluster，可以配置一個較大的值，對啟動多寫的galera cluster，較小的值比較合適，因為較大待執(zhí)行隊列長度意味著更大的沖突，默認值16
gcs.fc_factor：當待執(zhí)行隊列長度開始小于(gcs.fc_factor*gcs.fc_limit)時，數(shù)據(jù)同步恢復,默認0.5
gcs.fc_master_slave：galera cluster是否為Master-Slave模式，默認

安裝MariaDB Galera Cluster

安裝準備：

1. MariaDB Galera Cluster 5.5.28a RC
1) https://downloads./mariadb-galera/5.5.28a/
2) patched MariaDB 5.5.28，代碼中增加了Galera Library API（wsrep API），并在事務、鎖、handler等模塊添加/修改了調用邏輯

2. Galera wsrep provider
1) https:///galera/+download
2) Galera Library的實現(xiàn)，其中實現(xiàn)了group communication system, certification

編譯安裝

1. MariaDB Galera Cluster 5.5.28a RC
1) 與MariaDB基本相同，cmake時增加兩項：-DWITH_WSREP=ON , -DWITH_INNODB_DISALLOW_WRITES=1.
2. Galera wsrep provider: 源碼編譯后得到libgalera_smm.so(需要用到scons)

參數(shù)配置（每個節(jié)點）

wsrep_provider = /path/to/libgalera_smm.so
wsrep_cluster_address = cluster connection URL(后面詳細介紹)
binlog_format = ROW
default_storage_engine = INNODB
innodb_autoinc_lock_mode = 2
innodb_locks_unsafe_for_binlog = 1
選配：（可以提高性能，galera保證不丟數(shù)據(jù)）
innodb_flush_log_at_trx_commit = 2

構建集群（三個節(jié)點）

新建Galera Cluster

以galera_node1作為第一個節(jié)點新建集群，在my.cnf中配置參數(shù)：

wsrep_cluster_address = gcomm://
wsrep_cluster_name = galera_cluster
wsrep_node_address = 10.0.0.11
wsrep_node_name = galera_node1
wsrep_sst_method = rsync

添加galera_node2節(jié)點

在my.cnf中配置wsrep_cluster_address為node1的ip或者hostname

wsrep_cluster_address = gcomm://10.0.0.11
wsrep_cluster_name = galera_cluster
wsrep_node_address = 10.0.0.22
wsrep_node_name = galera_node2
wsrep_sst_method = rsync

添加galera_node3節(jié)點

在my.cnf中配置wsrep_cluster_address為node1的ip或者hostname

wsrep_cluster_address = gcomm://10.0.0.11
wsrep_cluster_name = galera_cluster
wsrep_node_address = 10.0.0.33
wsrep_node_name = galera_node3
wsrep_sst_method = rsync

多實例配置

因為測試機器資源有限，需要在同一臺機器上啟動多個mysqld實例，為每個mysqld配置兩個端口號（一個是mysql server端口號，默認3306；另外一個是wsrep端口號，默認4567），并修改部分wsrep配置參數(shù)，例如：

啟動后在每個節(jié)點執(zhí)行：

mysql> show status like ‘wsrep%’;

當看到下述狀態(tài)時:

wsrep_connected=ON
wsrep_ready=ON
wsrep_cluster_status =Primary
wsrep_cluster_size=3(節(jié)點個數(shù))

則galera集群建立成功，如下圖所示：

說明：
1. MariaDB Galera Cluster 5.5.28a RC源碼安裝，在編譯時若沒有打開-DWITH_WSREP=ON, -DWITH_INNODB_DISALLOW_WRITES=1，或者沒有配置任何wsrep相關參數(shù)，它運行時就是一個普通的mysqld實例
2. Galera cluster復制不依賴于binlog文件，因此mysql-binlog和log-slave-updates都可以不配置，當然如果需要記錄binlog，也可以打開
3. 需要以wsrep_cluster_address = gcomm://啟動第一個節(jié)點后，才能相繼添加其他節(jié)點

Galera相關參數(shù)配置

InnoDB 相關參數(shù)

galera補丁版的mysql在cmake時需要指定：
-DWITH_WSREP=ON , -DWITH_INNODB_DISALLOW_WRITES=1

galera 目前只支持Innodb/xtradb/mariad存儲引擎
default_storage_engine = INNODB

為了降低沖突，下列兩項需要設置
innodb_autoinc_lock_mode = 2
innodb_locks_unsafe_for_binlog = 1（gap不加鎖）

選配：（可以提高性能，galera保證不丟數(shù)據(jù)）
innodb_flush_log_at_trx_commit = 2

選配：galera可以不寫binlog，注釋binlog路徑理論上可以提高性能
#log-bin
#log-slave-updates=1

wsrep 相關參數(shù)

wsrep參數(shù)都是以wsrep_開頭的(30+個)，其中有一個字符串參數(shù)（wsrep_provider_options）可以配置50+個更底層的參數(shù)。
可以通過“show variables like wsrep%”查看，wsrep_開頭參數(shù)
詳情：http://www./wiki/doku.php?id=mysql_options_0.8

列舉幾個重要的參數(shù)：

wsrep_auto_increment_control：控制auto_increment_increment=#nodes和auto_increment_offset=#node_id，默認ON
wsrep_causal_reads：默認是在本地節(jié)點讀，讀到的可能不是最新數(shù)據(jù)，開啟后將讀到最新數(shù)據(jù)，但會增加響應時間，默認OFF
wsrep_certify_nonPK：為沒有顯示申明主鍵的表生成一個用于certification test的主鍵，默認ON
wsrep_cluster_address: 啟動節(jié)點時需要指定galera cluster的地址,作為cluster中第一個啟動的節(jié)點，wsrep_cluster_address=gcomm://,對于后續(xù)啟動的節(jié)點，wsrep_cluster_address=gcomm://node1,node2,node3	
wsrep_cluster_name: 所有node必須一樣, 默認my_test_cluster
wsrep_convert_LOCK_to_trx：將LOCK/UNLOCK TABLES轉換成BEGIN/COMMIT，默認OFF
wsrep_data_home_dir：galera會生成一些文件，默認使用mysql_data_dir，默認mysql_data_dir
wsrep_node_name：節(jié)點名稱
wsrep_on：session/global,設置為OFF時，事務將不會復制到其他節(jié)點，默認ON
wsrep_OSU_method：Online Schema Update設置，TOI/RSU(MySQL >= 5.5.17)，默認TOI
wsrep_provider：libgalera_smm.so的路徑，若沒有配置，galera復制不會啟動，默認none
wsrep_provider_options：很長的字符串變量，可以配置很多group communication system相關參數(shù)，很長很長...
wsrep_retry_autocommit：事務在沖突時重新嘗試的次數(shù)，默認1
wsrep_slave_threads：并行復制的slave線程數(shù)，默認4
wsrep_sst_method：Snapshot State Transter方法：mysqldump/rsync/xt，默認mysqldump

wsrep_provider_options
該參數(shù)是一個字符串，包含了group communication system中很多參數(shù)設置，配置時使用分號隔開：
wsrep_provider_options=”key_a=value_a;key_b=value_b;key_c=value_c”
詳情：http://www./wiki/doku.php?id=galera_parameters

列舉其中部分重要參數(shù)：

evs.send_window：節(jié)點一次可以發(fā)送的消息數(shù)目，默認4
evs.user_send_window：其與evs.send_window之間的差別類似于max_connections與max_user_connection，默認2
gcs.fc_factor：flow control參數(shù)，默認0.5
gcs.fc_limit：flow control參數(shù)，默認16
gcs.fc_master_slave：flow control參數(shù)，默認NO
gcs.recv_q_hard_limit：接收隊列的占用的最大內存，默認LLONG_MAX
gcs.recv_q_soft_limit：當接收隊列占用內存超過(gcs.recv_q_hard_limit*gcs.recv_q_soft_limit),復制被延遲，默認0.25
gmcast.listen_addr：節(jié)點用于接收其它節(jié)點消息的地址，默認tcp://0.0.0.0:4567
pc.checksum：是否對發(fā)送的消息做checksum，默認true
pc.ignore_sb：是否忽略split brain，默認false

一個例子

binlog_format=row 
default-storage-engine = INNODB 
innodb_autoinc_lock_mode = 2 
innodb_locks_unsafe_for_binlog = 1
wsrep_provider = /u01/mariadb-galera/lib/libgalera_smm.so 
wsrep_cluster_address = "gcomm://192.168.xxx.01" 
wsrep_cluster_name = galera 
wsrep_node_address = 192.168.xxx.xxx 
wsrep_node_name = slave 
wsrep_sst_method = rsync 
wsrep_slave_threads = 16 
wsrep_provider_options="gcache.page_size=128M;gcache.size=2G;gcs.fc_limit=512;gcs.fc_factor=0.9;evs.send_window=256;evs.user_send_window=128"

Galera status variables

Galera提供了很多以wsrep_開頭狀態(tài)參數(shù)監(jiān)控mysql狀態(tài)，通過show status like ‘wsrep%’可以查看：

wsrep_local_state_uuid：應該與wsrep_cluster_state_uuid一致，如363acc29-9160-11e2-0800-4316271a76e4
wsrep_last_committed：已經提交事務數(shù)目，所有節(jié)點之間相差不大，可以用來計算延遲
wsrep_replicated：從本地節(jié)點復制出去的write set數(shù)目
wsrep_replicated_bytes：從本地節(jié)點復制出去的write set的總共字節(jié)數(shù)
wsrep_received：本地節(jié)點接收來自其他節(jié)點的write set數(shù)目
wsrep_received_bytes：本地節(jié)點接收來自其他節(jié)點的write set的總共字節(jié)數(shù)
wsrep_local_commits：從本地節(jié)點發(fā)出的write set被提交的數(shù)目，不超過wsrep_replicated
wsrep_local_cert_failures：certification test失敗的數(shù)目
wsrep_local_bf_aborts：certification test通過的write set執(zhí)行過程中回滾的與其沖突的本地事務
wsrep_local_replays：事務被回滾（bf abort）重做的數(shù)目
wsrep_local_send_queue：發(fā)送隊列的長度
wsrep_local_send_queue_avg：從上次查詢狀態(tài)到目前發(fā)送隊列的平均長度，>0.0意味著復制過程被節(jié)流了
wsrep_local_recv_queue：接收隊列的長度
wsrep_local_recv_queue_avg：從上次查詢狀態(tài)到目前接收隊列的平均長度，>0.0意味著執(zhí)行速度小于接收速度
wsrep_flow_control_paused：從上次查詢狀態(tài)到目前處于flow control的時間占比，如0.388129
wsrep_flow_control_sent：從上次查詢狀態(tài)到目前節(jié)點發(fā)送出的FC_PAUSE消息數(shù)目，如1
wsrep_flow_control_recv：從上次查詢狀態(tài)到目前及節(jié)點接收的FC_PAUSE消息數(shù)目，如1
wsrep_cert_deps_distance：可以并行執(zhí)行的write set的最大seqno與最小seqno之間的平均差值，如1851.825751
wsrep_apply_oooe：隊列中事務并發(fā)執(zhí)行占比，值越高意味著效率越高
wsrep_commit_window：平均并發(fā)提交窗口大小
wsrep_local_state：節(jié)點的狀態(tài),取值1-6
wsrep_local_state_comment：節(jié)點的狀態(tài)描述，比如Synced
wsrep_incoming_addresses：集群中其它節(jié)點的地址，多個地址之間用逗號分隔
wsrep_cluster_conf_id：集群節(jié)點關系改變的次數(shù)（每次增加/刪除都會+1）
wsrep_cluster_size：集群節(jié)點個數(shù)
wsrep_cluster_state_uuid：集群uuid，所有節(jié)點應該一樣，如：363acc29-9160-11e2-0800-4316271a76e4
wsrep_cluster_status：集群的目前狀態(tài)，取值：PRIMARY（正常）/NON_PRIMARY（不一致）
wsrep_connected：節(jié)點是否連接到集群，取值：ON/OFF
wsrep_local_index：節(jié)點id
wsrep_provider_name：默認Galera
wsrep_provider_vendor：默認Codership Oy <info@>
wsrep_provider_version：wsrep版本，如：2.2(rXXXX)
wsrep_ready：節(jié)點是否可以接受查詢了，取值：ON/OFF

一個截圖：

如何檢查節(jié)點是否加入到集群

1. wsrep_cluster_state_uuid應該與其它所有節(jié)點相同
2. wsrep_cluster_conf_id應該與其它所有節(jié)點相同
3. wsrep_cluster_size應該是所有節(jié)點的數(shù)目
4. wsrep_cluster_status取值應該是：Primary
5. wsrep_ready取值應該是ON
6. wsrep_connected取值應該是ON

判斷復制過程是否出現(xiàn)問題

wsrep_flow_control_paused，正常情況下，其取值應該接近于0.0，大于0.0意味著有‘慢節(jié)點’影響了集群的速度，可以嘗試通過增大wsrep_slave_threads來解決

找出最慢的節(jié)點

wsrep_flow_control_sent,wsrep_local_recv_queue_avg兩個值最大的節(jié)點

參考： galera status ， galera monitoring

性能測試

由于galera同步復制在每個寫事務提交時都增加了replicate trx和certification test的開銷，因此性能遠遠低于異步MySQL實例

測試場景

使用TPCC進行測試，包含3組數(shù)據(jù)：
1、normal mysql: baseline，單個mysql server
2、galera (RTT: 0.5ms): 2-nodes galera cluster，單節(jié)點讀寫
3、galera (RTT: 15.2ms): 2-nodes galera cluster，單節(jié)點讀寫

tpmC結果:

TPS結果：

測試結論：

1. 相對于異步MySQL實例，Galera replication性能下降約60%左右
2. Galera最大性能不受RTT影響，RTT 較小時（0.5ms），在達到最大性能之前（32并發(fā)），性能下降并不明顯 （32并發(fā)下降25%，16并發(fā)性能下降更低），RTT較大時（15.2ms），在達到最大性能之前（64并發(fā)），相對于norml mysq性能下降一直到很明顯，當壓力逐漸增大，由于group io的原因，galera性能在達到最大時還會提高

Galera replicate for MySQL學習資料

1. codership官網(wǎng)
2.Percona MySQL blog搜索中Perocona XtranDB Cluster