Galera Cluster原理

1、簡介

Galera Cluster是Codership公司開發的一套免費開源的高可用方案，官網爲http://galeracluster.com。Galera Cluster即爲安裝了Galera的Mariadb集羣（本文只介紹Mariadb Garela集羣）。其自己具備multi-master特性，支持多點寫入。Galera Cluster的三個（或多個）節點是對等關係，每一個節點均支持寫入，集羣內部會保證寫入數據的一致性與完整性，具體實現原理會在本篇中作簡要介紹。
官方給出的特性以下：

• 真正的多主集羣，Active-Active架構；
• 同步複製，沒有複製延遲；
• 多線程複製；
• 沒有主從切換操做，無需使用虛IP；
• 熱備份，單個節點故障期間不會影響數據庫業務；
• 支持節點自動加入，無需手動拷貝數據；
• 支持InnoDB存儲引擎；
• 對應用程序透明，原生MySQL接口；
• 無需作讀寫分離；
• 部署使用簡單。

2、基於認證的複製

有關同步複製與異步複製在此就不贅述了，介紹一下基於認證的複製方式。
工做原理以下：

當客戶端提交一個commit命令，在事務提交以前，全部對數據庫的操做都會被寫入write-set中，包括主鍵，，而後數據庫會將這個write-set發給全部其餘節點，write-set將在每一個節點（包括生成write-set的節點）上使用主鍵進行認證嘗試。
若是認證失敗，節點會丟棄這個write-set，同時集羣會回滾到以前的事務點；若是認證成功，commit正常提交，事務會應用到其餘節點上。
Galera Cluster基於認證的複製主要依賴於the global ordering of transactions，咱們暫且稱其爲全局事務序號，複製期間，Galera Cluster會爲每個事務分配一個全局事務序號，相似序列號。當某個事務到達commit階段時，節點會檢查待提交事務的序號與上一次成功提交事務的序號，檢查區間全部事務是否與新事務存在主鍵衝突，若是檢查到衝突，認證就會失敗。
全部節點以相同的順序接受事務，全部節點對事務是否提交作一致性決定。事務提交成功以後，首先生成此事務的節點會通知應用程序事務已正確提交。

3、內部架構

數據同步使用同步複製（Eager Replication），集羣中的節點經過更新單個事務來與集羣中的節點進行同步，這意味着當事務進行提交時，全部節點都具備相同的值。
內部架構以下：

主要有如下幾個組件組成：
DBMS：Database Management System，即咱們常見的數據庫，Galera Cluster支持MySQL、MariaDB和Percona XtraDB。
wsrep API：寫集複製功能組件，負責提供關係型數據庫管理、複製服務，提供接口。
Galera Replication Plugin：啓用寫集複製功能的插件。
Group Communication plugins：Galera Clsuter集羣中各類羣組通訊系統，例如gcomm和Spread。

4、數據複製方式

將集羣中的數據複製到某個節點上實現備份，或者節點新加入集羣須要同步數據。
Galera Cluster有兩種數據複製方式：

• State Snapshot Transfers (SST)：全量同步
• Incremental State Transfers (IST)：增量同步

簡單來說。SST就是同步整個數據庫，IST是同步一個庫與另外一個庫相差的部分事務。

一、State Snapshot Transfers (SST)

當一個節點新加入集羣時，新加入的節點會向集羣中已存在的某個節點開始進行全量同步，全量同步中有兩種不一樣的方式：
Logical：這種方法其實就是經常使用的mysqldump。在同步以前須要同步的數據庫須要初始化，即沒有任何多餘的數據。這是一種加鎖的方式，傳輸期間，數據庫會變成read-only，同時，同步的主庫上會運行一個殺傷性比較大的FLUSH TABLES WITH READ LOCK命令。下面簡單介紹一下這個命令，來看看爲何要說它殺傷力比較大。
FLUSH TABLES WITH READ LOCK命令簡稱FTWRL，該命令主要用於備份工具獲取一致性備份，因爲FTWRL命令總共須要持有兩把全局MDL鎖，而且還須要關閉全部表對象，因此會說它殺傷性比較大。執行此命令容易形成庫hang住，若是在主庫上執行此命令，容易形成業務異常，若是在備庫上執行，容易形成SQL線程卡住，形成主備複製延遲。
Physical：這種方式使用rsync, rsync_wan, xtrabackup和其餘一些方式直接將數據文件從一個節點複製到另外一個節點上，簡單粗暴！這種方式比mysqldump要快，但限制也挺多的。

二、Incremental State Transfers (IST)

這種複製方式會驗證從庫落後的事務，而後將這部分發送過去，而不是將整個數據庫進行同步。
這種方式有兩個限制：

• 一、新加入節點的state UUID須要與集羣的一致（能夠用show status like '%wsrep%'命令進行確認）；
• 二、全部落後的write-sets須要在主庫的write-set cache中存在。

下面用個例子來簡單介紹一下：
假設如今有一個節點趕不上集羣的進度了，它的node state爲

a76ef62-30ec-11e1-0800-dba504cf2aab:197222

同時，集羣中的一個節點的note state爲

5a76ef62-30ec-11e1-0800-dba504cf2aab:201913

主庫（咱們姑且這樣稱呼，比較好辨認）收到從庫的同步請求以後，塔會在本身的write-set cache查找sequence number 197223，若是沒有找着，就開始進行SST，若是能找着，主庫就將197223到201913的commit同步給從庫。
注意：從實現原理上，咱們就能發現，write-set cache的大小將直接決定能進行多少增量複製，在主庫上由gcache.size來決定使用多大的內存來存儲write-sets。此值設置過大太小都很差，須要根據本身環境來合理設置。