PXC簡介：

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臨界區中出來，從而讓其他事務繼續提交；