MySQL高可用――PXC解說

2024-07-24 12:31:30

字體：大中小

來源：轉載

供稿：網友

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

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

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

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

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

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

首先客戶端先發起一個事務，該事務先在本地執行，執行完成之后就要發起對事務的提交操作了。在提交之前需要將產生的復制寫集廣播出去，然后獲取到一個全局的事務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的工作模式：

  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_replay_trx：

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

---galera_append_key：

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

---galera_append_data：

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