碼迷,mamicode.com
首頁 > 數據庫 > 詳細

MySQL高可用——PXC簡介

時間:2018-07-27 15:33:15      閱讀:9426      評論:0      收藏:0      [點我收藏+]

標簽:2gb   主鍵   地址   innodb   產品   backup   serve   相同   判斷   

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


MySQL高可用——PXC簡介

標簽:2gb   主鍵   地址   innodb   產品   backup   serve   相同   判斷   

原文地址:http://blog.51cto.com/fengfeng688/2151059

(0)
(2)
   
舉報
評論 一句話評論(0
登錄后才能評論!
? 2014 mamicode.com 版權所有 京ICP備13008772號-2
迷上了代碼!
公式规律下期单双