galera產品是以galera cluster方式為mysql提高高可用集群解決方案的。galera cluster就是集成了galera插件的mysql集群。galera replication是codership提供的mysql數據同步方案，具有高可用性，方便擴展，並且可以實現多個mysql節點間的數據同步復制與讀寫，可保障數據庫的服務高可用及數據強一致性。

PXC屬於一套近乎完美的mysql高可用集群解決方案，相比那些比較傳統的基於主從復制模式的集群架構MHA和MM+keepalived，galera cluster最突出特點就是解決了詬病已久的數據復制延遲問題，基本上可以達到實時同步。而且節點與節點之間，他們相互的關系是對等的。本身galera cluster也是一種多主架構。galera cluster最關註的是數據的一致性，對待事物的行為時，要麽在所有節點上執行，要麽都不執行，它的實現機制決定了它對待一致性的行為非常嚴格，這也能非常完美的保證MySQL集群的數據一致性；

對galera cluster的封裝有兩個，雖然名稱不同，但實質都是一樣的，使用的都是galera cluster。一個MySQL的創始人在自己全新的MariaDB上實現的MAriaDB cluster；一個是著名的MySQL服務和工具提供商percona實現的percona xtradb cluster，簡稱PXC

要搭建PXC架構至少需要3個mysql實例來組成一個集群，三個實例之間不是主從模式，而是各自為主，所以三者是對等關系，不分從屬，這就叫multi-master架構。客戶端寫入和讀取數據時，連接哪個實例都是一樣的。讀取到的數據時相同的，寫入任意一個實例之後，集群自己會將新寫入的數據同步到其他實例上，這種架構不共享任何數據，是一種高冗余架構。

--：galera cluster的功能有7點，如下：

①：多主架構：真正的多點讀寫集群，在任何時候讀寫的數據都是最新的；

②：同步復制：集群不同節點之間的數據同步，沒有延遲，在數據庫掛掉之後，數據不會丟失；

③：並發復制：從節點在apply數據時，支持並行執行，有更好的性能表現

④：故障切換：因為支持多點寫入，所以在出現數據庫故障時可以很容易的進行故障切換

⑤：熱插拔：在服務期間，如果數據庫掛了，只要監控程序發現的夠快，不可服務時間就會非常少，在節點故障期間，節點本身對集群的影響非常小；

⑥：自動節點克隆：在新增節點或停機維護時，增量數據或基礎數據不需要人工手動備份提供，galera cluster會自動拉取在線節點數據，集群最終會變為一致；

⑦：對應用透明：集群的維護，對應用程序是透明的，幾乎感覺不到；

--PXC原理：

PXC最常使用以下4個端口號：

3306-數據庫對外服務的端口號。

4444-請求SST的端口（SST是指數據庫一個備份全量文件的傳輸。）

4567-組成員之間進行溝通的一個端口號

4568-用於傳輸IST（相對於SST來說的一個增量）

PXC的操作流程：

首先客戶端先發起一個事務，該事務先在本地執行，執行完成之後就要發起對事務的提交操作了。在提交之前需要將產生的復制寫集廣播出去，然後獲取到一個全局的事務ID號，一並傳送到另一個節點上面。通過合並數據之後，發現沒有沖突數據，執行apply_cd和commit_cb動作，否則就需要取消此次事務的操作。而當前server節點通過驗證之後，執行提交操作，並返回OK，如果驗證沒通過，則執行回滾。當然在生產中至少要有3個節點的集群環境，如果其中一個節點沒有驗證通過，出現了數據沖突，那麽此時采取的方式就是講出現不一致的節點踢出集群環境，而且它自己會執行shutdown命令，自動關機。

PXC的優點：

①：實現mysql數據庫集群架構的高可用性和數據的 強一致性。

②：完成了真正的多節點讀寫的集群方案。

③：改善了傳統意義上的主從復制延遲問題，基本上達到了實時同步。

④：新加入的節點可以自動部署，無須提供手動備份，維護起來很方便。

⑤：由於是多節點寫入，所以數據庫故障切換很容易。

PXC的缺點：

①：新加入的節點開銷大，需要復制完整的數據。采用SST傳輸開銷太大。

②：任何更新事務都需要全局驗證通過，才會在每個節點庫上執行。集群性能受限於性能最差的節點，也就是經常說的短板效應。

③：因為需要保證數據的一致性，所以在多節點並發寫時，鎖沖突問題比較嚴重。

④：存在寫擴大問題，所有的節點上都會發生些操作。

⑤：只支持innodb存儲引擎的表。

⑥：沒有表級別的鎖定，執行DDL語句操作會把整個集群鎖住，而且也 kill 不了（建議使用Osc操作，即在線DDL）

⑦：所有的表必須含有主鍵，不然操作數據時會報錯。

PXC搭建的註意點：

首先要規範集群中節點的數量，整個集群中節點數控制在最少3個、最多8個範圍內。最少3個節點是為了防止出現腦裂現象，因為只有在兩個節點下才會出現此現象。腦裂現象的標誌就是輸入任何命令、返回結果都是unkown command，節點在集群中，會因為新節點的加入或者故障，同步失效等而發生狀態的切換。

--節點狀態變化階段：

open：節點啟動成功，嘗試連接到集群。

primary：節點已處於集群中，在新節點加入時，選取donor進行數據同步時會產生的狀態。

joiner：節點處於等待接收同步文件時的狀態。

joined：節點完成數據同步的工作，嘗試保持和集群進度一致。

synced：節點正常提供服務的狀態，表示已經同步完成並和集群進度保持一致。

doner：節點處於為新加入的節點提供全量數據時的狀態。

註意：doner節點就是數據的貢獻者，如果一個新節點加入集群，此時又需要大量數據的SST傳輸，就有可能因此而拖垮整個集群的性能。所以在生產環境中，如果數據量小，還可以使用SST全量傳輸，但如果數據量很大就不建議使用這種方式了。可以考慮先建立主從關系，在加入集群。

PXC有兩種節點的數據傳輸方式：一種叫SST全量傳輸，另一種叫IST增量傳輸。

SST傳輸有：xtrabackup、mysqldump和rsync三種方法。而增量傳輸就一種方法就是xtrabackup。但生產環境中一般數據量不大的時候，可以使用SST全量傳輸，但也只實現xtrabackup方法。

在PXC中還有一個特別重要的模塊就是GCache。它的核心功能就是每個節點緩存當前最新的寫集。如果有新節點加入進來，就可以把新數據的增量傳遞給新節點，而不需要再使用SST方式了。這樣可以讓節點更快地加入集群中。涉及參數如下：

gcache.size：代表用來緩存寫集增量信息的大小。它的默認大小是128MB，通過wsrep_provider_options參數設置。建議調整為2GB-4GB範圍，足夠的空間便於緩存更多的增量信息。

gcache.mem_size：代表gcache中內存緩存的大小，適度調大可以提高整個集群的性能。

gcache.page_size：可以理解為如果內存不夠用（gcache不足），就直接將寫集寫入磁盤文件中。

--：PXC的工作模式：

galera的工作模式是——某個節點寫入一個事務，它會廣播到其他節點，而這個所謂的其他節點，也包括自己。也就說自己發出來的事務，自己也會收到，只是在收到並產生GTID之後，就被簡單忽略了，而不會再去apply一次。

--：galera的並發控制機制：

並發控制主要是在接口galera_pre_commit中完成的，這個接口是galera最重要的接口之一，這裏面實現了最重要的復制、驗證邏輯。目前，這個接口中包括的並發控制有以下幾點：

①：數據復制：

目前的galera版本中，寫集數據的發送是通過asio的異步方式將數據廣播出去。這個發送是串行的，是一個臨界區，因為在每次 發送前，邏輯上還需要分片，並且每次發送完成之後，需要等待一個GTID的值，所以為了保證數據的一致性，這個發送操作需要串行；

②：寫集驗證：

要求所有進入處理區的GTID必須是順序的，因為GTID是順序產生的，所以在順序的基礎上，同一時間必須只有一個事務可以進行處理，說白了就是串行；

受這種層次並發控制管理的操作主要有驗證操作，因此說驗證是串行的；

③：寫集apply

④：事務commit

這個層次的並發控制機制，默認是3，建議也是3，就是串行提交，這樣就保證了不管在主庫還是從庫，所有的節點產生的binlog都是完全相同的；

3、galera 接口：

---galera_init：

這個接口的作用是初始化一個galera節點，這是一個PXC節點調用的第一個wsrep接口，在啟動服務器的時候初始化，將所有需要的參數和環境變量初始化。（如：集群名字，實例地址、需要這個接口做binlog的復制等）

---galera_connect：

這個接口是第二個調用的接口。這個接口的作用是將當前節點加入集群中。加入集群前會調用函數wsrep_view_handler_cb來判斷新加入節點與集群的數據是否同步；

---galera_recv：

這個接口的作用是，在這個函數裏阻塞式的接收其他節點及本節點發送的數據，並且調用復制apply函數執行復制操作。（這個接口實際上是可以並行存在的。它對應的是參數wsrep_slave_threads有多少個線程，就有多少個galera_recv的調用）

---galera_pre_commit：

這個接口是galera最重要的接口之一。它的作用包括兩部分，首先是將當前指定的事務寫集廣播給整個集群節點，然後就是驗證，如果驗證成功，則將處理權交給上層，繼續做數據庫事務的提交操作；這個接口是在數據庫事務提交時調用的，調用這個接口時，必須是本地事務已經執行完成；

---galera_replay_trx：

這個接口的作用及使用，就是在驗證過程中，由於數據庫鎖的沖突，當前操作被其他線程自治縣了galera_abort_pre_com_mit，導致當前線程被強制中止，但是由於寫集已經復制到其他節點，所以本節點這個事務必須要完成。通過這個接口，將這個事務的寫集做一次apply，所以就叫replay；

---galera_append_key：

這個接口就是所謂的galera驗證，被驗證的對象實際上就是寫集，而構成寫集的內容，其實就是通過這個接口來完成的；

---galera_append_data：

這個接口是當前事務所生成的binlog內容，也就是說key在驗證通過之後，使用data在從節點執行，即可做到數據同步；

---galera_post_commit：

這個接口是用來真正提交事務的。這個接口包括4個功能：更新狀態參數wsrep_last_committed的值，表示當前事務已經真正提交了；更新參數wsrep_local_commits的值，表示本地又成功提交了一個事務；檢查當前驗證寫集緩沖區是不是可以做purge操作；

---galera_to_execute_start:

這個接口專門用來處理DDL語句的執行；

---galera_to_execute_end：

這個接口實際上和galera_post_commit功能一樣，成對出現，是為處理不同語句而設置的，主要就是為了從commit臨界區中出來，從而讓其他事務繼續提交；

MySQL高可用——PXC簡介