碼上快樂

相關內容    簡體    繁體

mysql pxc集群 原理 （圖解+秒懂+史上最全）

本文轉載自   查看原文   2021-09-27 18:16   825 

文章很長，建議收藏起來，慢慢讀！ Java 高並發 發燒友社群：瘋狂創客圈 奉上以下珍貴的學習資源：

推薦：入大廠 、做架構、大力提升Java 內功 的 精彩博文

入大廠 、做架構、大力提升Java 內功 必備的精彩博文 2021 秋招漲薪1W + 必備的精彩博文
1：Redis 分布式鎖 （圖解-秒懂-史上最全） 2：Zookeeper 分布式鎖 （圖解-秒懂-史上最全）
3: Redis與MySQL雙寫一致性如何保證？ （面試必備） 4: 面試必備：秒殺超賣 解決方案 （史上最全）
5:面試必備之：Reactor模式 6: 10分鍾看懂， Java NIO 底層原理
7:TCP/IP（圖解+秒懂+史上最全） 8：Feign原理 （圖解）
9:DNS圖解（秒懂 + 史上最全 + 高薪必備） 10：CDN圖解（秒懂 + 史上最全 + 高薪必備）
11: 分布式事務（ 圖解 + 史上最全 + 吐血推薦 ） 12：seata AT模式實戰（圖解+秒懂+史上最全）
13：seata 源碼解讀（圖解+秒懂+史上最全） 14：seata TCC模式實戰（圖解+秒懂+史上最全）
Java 面試題 30個專題 , 史上最全 , 面試必刷 阿里、京東、美團... 隨意挑、橫着走！！！
1： JVM面試題（史上最強、持續更新、吐血推薦） 2：Java基礎面試題（史上最全、持續更新、吐血推薦
3：架構設計面試題 （史上最全、持續更新、吐血推薦） 4：設計模式面試題 （史上最全、持續更新、吐血推薦）
17、分布式事務面試題 （史上最全、持續更新、吐血推薦） 一致性協議 （史上最全）
29、多線程面試題（史上最全） 30、HR面經，過五關斬六將后，小心陰溝翻船！
9.網絡協議面試題（史上最全、持續更新、吐血推薦） 更多專題， 請參見【 瘋狂創客圈 高並發 總目錄 】
SpringCloud 精彩博文
nacos 實戰（史上最全） sentinel （史上最全+入門教程）
SpringCloud gateway （史上最全） 更多專題， 請參見【 瘋狂創客圈 高並發 總目錄 】

背景：

下一個視頻版本，從架構師視角，尼恩為大家打造高可用、高並發中間件的原理與實操。

目標：通過視頻和博客的方式，為各位潛力架構師，徹底介紹清楚架構師必須掌握的高可用、高並發環境，包括但不限於：

  • 高可用、高並發nginx架構的原理與實操

  • 高可用、高並發mysql架構的原理與實操

  • 高可用、高並發nacos架構的原理與實操

  • 高可用、高並發rocketmq架構的原理與實操

  • 高可用、高並發es架構的原理與實操

  • 高可用、高並發minio架構的原理與實操

在這里插入圖片描述

why 高可用、高並發中間件的原理與實操：

  • 實際的開發過程中，很多小伙伴聚焦crud開發，環境出了問題，都不能啟動。

  • 作為架構師，或者未來想走向高端開發，或者做架構，必須掌握高可用、高並發中間件的原理，掌握其實操。

Mysql集群的背景

單機單點的數據庫，一旦這台機子宕機(機器出現故障、機房停電、...)，那整個網站將無法正常訪問。

單節點的數據庫無法滿足性能上的要求，就像校園網查成績的時候，如果1萬人同時查，你可能拿到就是一個白屏，無論你是收費的還是免費的數據庫，單節點都滿足不了這種並發需求

單節點的數據庫沒有冗余設計，無法滿足高可用，一旦這個機器出現問題，沒有其他節點的數據庫頂替，那網站將無法正常訪問

這時候集群就出現了，一台機器出現問題了，另外的機器還在正常運行，網站依舊可以訪問。

集群案例：滴滴出行、淘寶、京東、斗魚直播、支付寶、微信、QQ

單節點數據庫的弊端

無論是 數據庫訪問的流量 還是 數據體量， 達到了單庫單表的瓶頸之后，（具體具體請參見尼恩的秒殺架構視頻），都需要分庫。

下面就是一個案例，具體的案例太多啦。 so， mysql集群的原理和實操，大家一定需要掌握。

在這里插入圖片描述

高可用高並發MYSQL案例

1.天貓雙十一

　　2017年天貓雙十一的交易額達到1682億元，3分鍾破百億，9小時破千億

　　交易峰值(下訂單的峰值)：32.5萬/秒

　　支付峰值：25.6萬/秒

　　數據庫峰值：4200萬/秒

　　支持這么漂亮的數字完美運行，除了數據庫集群技術還有雲服務器、負載均衡、RDS雲數據庫等技術

2.微信紅包

　　

2017年除夕當天，全國人民總共收發142億個紅包，峰值42萬/秒

央視春晚微信搖一搖互動總量達110萬億次，峰值8.1億/秒

學習目標和方式

1）向大型互聯網應用看起，學習架構設計和業務處理

2）掌握PXC集群MySQL方案的原理

3）掌握PXC集群的強一致性

4）掌握PXC集群的高可用方案

5）解決實際的問題

來自小伙伴的具體的生產環境問題：

尼恩老師，能請教個問題嗎?

一個工作上的問題，我們項目的登錄功能數據查詢都是直接從數據庫直接讀取，現在提升下一下登錄並發能力，我們的用戶大概是200百萬，並且用戶登錄和注冊是同一個接口，這種情況該怎么優化，您能幫出個主意嗎

在這里插入圖片描述

在這里插入圖片描述

PXC簡介

PXC（Percona XtraDB Cluster）是一個開源的MySQL高可用解決方案。

Percona XtraDB Cluster（簡稱PXC集群）提供了MySQL高可用的一種實現方法。

1）集群是有節點組成的，推薦配置至少3個節點，但是也可以運行在2個節點上。

2）每個節點都是普通的mysql/percona服務器，可以將現有的數據庫服務器組成集群，反之，也可以將集群拆分成單獨的服務器。

3）每個節點都包含完整的數據副本。

MySQL高可用之PXC_mysql

在這里插入圖片描述

MySQL分支的選擇：Percona還是MariaDB

在MySQL被Oracle收購以后，越來越多的人對於MySQL的前景表示了擔憂，對於開源的MySQL，或多或少對於Oracle自家的數據庫產品產生沖擊，這個開源免費的MySQL 對於Oracle更多的是包袱而不是資產。

比如淘寶就從Oracle轉成了MySQL，一些大型互聯網公司也在推行去IOE(I:IBM,O:Oracle,E:EMC)，甲骨文公司收購了MySQL后，有將MySQL閉源的潛在風險，因此社區采用分支的方式來避開這個風險。

img

Percona

在介紹 Percona 之前，首要要介紹的是XtraDB存儲引擎，在MYSQL中接觸比較多的是MyISAM和InnoDB這兩個存儲引擎。MySQL 4和5使用默認的MyISAM存儲引擎安裝每個表。從5.5開始，MySQL已將默認存儲引擎從MyISAM更改為InnoDB。

MyISAM沒有提供事務支持，而InnoDB提供了事務支持。

與MyISAM相比，InnoDB提供了許多細微的性能改進，並且在處理潛在的數據丟失時提供了更高的可靠性和安全性。

Percona XtraDB 是 InnoDB 存儲引擎的增強版，被設計用來更好的使用更新計算機硬件系統的性能，同時還包含有一些在高性能環境下的新特性。

Percona XtraDB 存儲引擎是完全的向下兼容，在 MariaDB 中，XtraDB 存儲引擎被標識為”ENGINE=InnoDB”，這個與 InnoDB 是一樣的，所以你可以直接用XtraDB 替換掉 InnoDB 而不會產生任何問題。

Percona XtraDB 包含有所有 InnoDB’s 健壯性，可依賴的 ACID 兼容設計和高級 MVCC 架構。

XtraDB 在 InnoDB 的堅實基礎上構建，使 XtraDB 具有更多的特性，更好調用，更多的參數指標和更多的擴展。從實踐的角度來看，XtraDB 被設計用來在多核心的條件下更有效的使用內存和更加方便，更加可用。

新的特性被用來降低 InnoDB 的局限性。性能層面，XtraDB與內置的MySQL 5.1 InnoDB 引擎相比，它每分鍾可處理2.7倍的事務。

Percona Server由領先的MySQL咨詢公司Percona發布。

Percona Server是一款獨立的數據庫產品，其可以完全與MySQL兼容，可以在不更改代碼的情況了下將存儲引擎更換成XtraDB 。

Percona團隊的最終聲明是“Percona Server是由Oracle發布的最接近官方MySQL Enterprise發行版的版本”，因此與其他更改了大量基本核心MySQL代碼的分支有所區別。Percona Server的一個缺點是他們自己管理代碼，不接受外部開發人員的貢獻，以這種方式確保他們對產品中所包含功能的控制。

MariaDB

MariaDB由MySQL的創始人麥克爾·維德紐斯主導開發，他早前曾以10億美元的價格，將自己創建的公司MySQL AB賣給了SUN，此后，隨着SUN被甲骨文收購，MySQL的所有權也落入Oracle的手中。

MariaDB名稱來自麥克爾·維德紐斯的女兒瑪麗亞（英語：Maria）的名字。

MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能輕松成為MySQL的代替品。在存儲引擎方面，10.0.9版起使用XtraDB（名稱代號為Aria）來代替MySQL的InnoDB。

版本方面，MariaDB直到5.5版本，均依照MySQL的版本。

因此，使用MariaDB5.5的人會從MySQL 5.5中了解到MariaDB的所有功能。從2012年11月12日起發布的10.0.0版開始，不再依照MySQL的版號。

10.0.x版以5.5版為基礎，加上移植自MySQL 5.6版的功能和自行開發的新功能。

相對於最新的MySQL5.6，MariaDB在性能、功能、管理、NoSQL擴展方面包含了更豐富的特性。比如微秒的支持、線程池、子查詢優化、組提交、進度報告等。

https://mariadb.org/

Percona OR MariaDB

選擇是一件痛苦的事情，對於上面的兩個數據庫，就是大公司也存在分歧，就像淘寶目前使用的是Percona 5.5.18，而Google、Wikipedia則站在了MariaDB這邊。具體哪一個會走的更遠，我們就拭目以待吧。

基於Galera的高可用方案

不幸的是，傳統架構的使用，一直被人們所詬病，因為MySQL的主從模式，天生的不能完全保證數據一致，很多大公司會花很大人力物力去解決這個問題，而效果卻一般，可以說，只能是通過犧牲性能，來獲得數據一致性，但也只是在降低數據不一致性的可能性而已。

問題：MySQL的主從模式，天生的不能完全保證數據一致，why?

具體答案，請參見配套視頻。

所以現在就急需一種新型架構，從根本上解決這樣的問題，天生的擺脫掉主從復制模式這樣的“美中不足”之處了。

幸運的是，MySQL的福音來了，Galera Cluster就是我們需要的——從此變得完美的架構。

基於Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster，目前PXC架構在生產線上用的更多而且更成熟一些。

Galera Cluster

  • 由 Codership 開發 官網
  • 包含在MariaDB，在Percona、MySQL 都可以使用

Galera Cluster 是一個基於 InnoDB 多主的同步復制，可以讀寫任何節點，即使失去任何一個節點也不影響業務中斷，而且無需復雜的 failover 操作。

Percona XtraDB Cluster

  • 由 Percona 開發，在 Galera 基礎打 Patch [官網](https://www.percona.com/software/mysql- database/percona-xtradb-cluster)
  • 自 2012 年 4 月可用
  • 附加的特性
    • PFS 擴展支持
    • SST/XtraBackup 方式的改變
    • PXC Strict mode
    • ProxySQL 集成
    • 提升性能

MariaDB Galera Cluster

1.簡述：

MariaDB Galera Cluster 是一套在mysql innodb存儲引擎上面實現multi-master及數據實時同步的系統架構，業務層面無需做讀寫分離工作，數據庫讀寫壓力都能按照既定的規則分發到各個節點上去。在數據方面完全兼容 MariaDB 和 MySQL。

在 Galera 基礎打 Patch

2.特性：

​ (1).同步復制 Synchronous replication

​ (2).Active-active multi-master 拓撲邏輯

​ (3).可對集群中任一節點進行數據讀寫

​ (4).自動成員控制，故障節點自動從集群中移除

​ (5).自動節點加入

​ (6).真正並行的復制，基於行級

​ (7).直接客戶端連接，原生的 MySQL 接口

​ (8).每個節點都包含完整的數據副本

​ (9).多台數據庫中數據同步由 wsrep 接口實現

3.局限性

​ (1).目前的復制僅僅支持InnoDB存儲引擎,任何寫入其他引擎的表，包括mysql.*表將不會復制,但是DDL語句會被復制的,因此創建用戶將會被復制,但是insert into mysql.user…將不會被復制的.

​ (2).DELETE操作不支持沒有主鍵的表,沒有主鍵的表在不同的節點順序將不同,如果執行SELECT…LIMIT… 將出現不同的結果集.

​ (3).在多主環境下LOCK/UNLOCK TABLES不支持,以及鎖函數GET_LOCK(), RELEASE_LOCK()…

​ (4).查詢日志不能保存在表中。如果開啟查詢日志，只能保存到文件中。

​ (5).允許最大的事務大小由wsrep_max_ws_rows和wsrep_max_ws_size定義。任何大型操作將被拒絕。如大型的LOAD DATA操作。

​ (6).由於集群是樂觀的並發控制，事務commit可能在該階段中止。如果有兩個事務向在集群中不同的節點向同一行寫入並提交，失敗的節點將中止。對於集群級別的中止，集群返回死鎖錯誤代碼(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).

​ (7).XA事務不支持，由於在提交上可能回滾。

​ (8).整個集群的寫入吞吐量是由最弱的節點限制，如果有一個節點變得緩慢，那么整個集群將是緩慢的。為了穩定的高性能要求，所有的節點應使用統一的硬件。

​ (9).集群節點建議最少3個。

​ (10).如果DDL語句有問題將破壞集群。

Galera Cluster方案的優勢

本身Galera Cluster也是一種多主架構。

相比傳統的主從復制架構，Galera Cluster解決的最核心問題是，在三個實例（節點）之間，它們的關系是對等的，multi-master架構的，在多節點同時寫入的時候，能夠保證整個集群數據的一致性，完整性與正確性。

在傳統MySQL的使用過程中，也不難實現一種multi-master架構，但是一般需要上層應用來配合，比如先要約定每個表必須要有自增列，並且如果是2個節點的情況下，一個節點只能寫偶數的值，而另一個節點只能寫奇數的值，同時2個節點之間互相做復制，因為2個節點寫入的東西不同，所以復制不會沖突，在這種約定之下，可以基本實現多master的架構，也可以保證數據的完整性與一致性。但這種方式使用起來還是有限制，同時還會出現復制延遲，並且不具有擴展性，不是真正意義上的集群。

PXC相比那些傳統的基於主從模式的集群架構MHA和雙主，Galera Cluster 最突出的特點就是解決了詬病已久的復制延遲問題，基本上可以達到實時同步。

而且節點與節點之間，它們互相的關系是對等的。

PXC是在存儲引擎層實現的同步復制，而非異步復制，所以其數據的一致性是相當高的。

MySQL Group Replication

  • 由 Oracle 官方開發
  • 2016 年 12 月 MySQL 5.7.17 發布 GA
  • MySQL InnoDB Cluster 整體解決方案

MySQL Group Replication 是一個 MySQL Server Plugin，提供分布式狀態機復制與 Server 強大協調，當在一個 Group Replication 時，Server 將自動協調，每個節點都可以自動處理更新，自動檢測，有一個 membership service 維護一個 view，記錄組內 記錄可見成員在某個時間點一致性和高可用性的，當任何一個成加入或離開，view 就會相應的更新

MMM

MMM是在MySQL Replication的基礎上，對其進行優化。

MMM（Master Replication Manager for MySQL）是雙主多從結構，這是Google的開源項目，使用Perl語言來對MySQL Replication做擴展，提供一套支持雙主故障切換和雙主日常管理的腳本程序，主要用來監控mysql主主復制並做失敗轉移。

注意：這里的雙主節點，雖然叫做雙主復制，但是業務上同一時刻只允許對一個主進行寫入，另一台備選主上提供部分讀服務，以加速在主主切換時刻備選主的預熱。

就各個集群方案來說，其優勢為：

  • 自動的主主Failover切換，一般3s以內切換備機。
  • 多個從節點讀的負載均衡。

其劣勢為：

  • 無法完全保證數據的一致性。如主1掛了，MMM monitor已經切換到主2上來了，而若此時雙主復制中，主2數據落后於主1（即還未完全復制完畢），那么此時的主2已經成為主節點，對外提供寫服務，從而導致數據不一。
  • 由於是使用虛擬IP浮動技術，類似Keepalived，故RIP（真實IP）要和VIP（虛擬IP）在同一網段。如果是在不同網段也可以，需要用到虛擬路由技術。但是絕對要在同一個IDC機房，不可跨IDC機房組建集群。

MHA

MHA是在MySQL Replication的基礎上，對其進行優化。

MHA（Master High Availability）是多主多從結構，這是日本DeNA公司的youshimaton開發，主要提供更多的主節點，但是缺少VIP（虛擬IP），需要配合keepalived等一起使用。

要搭建MHA，要求一個復制集群中必須最少有三台數據庫服務器，一主二從，即一台充當master，一台充當備用master，另外一台充當從庫。

技術圖片

就各個集群方案來說，其優勢為：

  • 可以進行故障的自動檢測和轉移
  • 具備自動數據補償能力，在主庫異常崩潰時能夠最大程度的保證數據的一致性。

其劣勢為：

  • MHA架構實現讀寫分離，最佳實踐是在應用開發設計時提前規划讀寫分離事宜，在使用時設置兩個連接池，即讀連接池與寫連接池，也可以選擇折中方案即引入SQL Proxy。但無論如何都需要改動代碼；
  • 關於讀負載均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能實現負載均衡、故障檢查及備升級為主后的讀寫剝離功能即可，建議使用LVS

Galera Cluster

Galera Cluster是由Codership開發的MySQL多主結構集群，這些主節點互為其它節點的從節點。

於MySQL原生的主從異步復制，Galera采用的是多主同步復制，並針對同步復制過程中，會大概率出現的事務沖突和死鎖進行優化，就是復制不基於官方binlog而是Galera復制插件，重寫了wsrep api。

異步復制中，主庫將數據更新傳播給從庫后立即提交事務，而不論從庫是否成功讀取或重放數據變化。這種情況下，在主庫事務提交后的短時間內，主從庫數據並不一致。

同步復制時，主庫的單個更新事務需要在所有從庫上同步 更新。換句話說，當主庫提交事務時，集群中所有節點的數據保持一致。

對於讀操作，從每個節點讀取到的數據都是相同的。對於寫操作，當數據寫入某一節點后，集群會將其同步到其它節點。

技術圖片

就各個集群方案來說，其優勢為：

  • 多主多活下，可對任一節點進行讀寫操作，就算某個節點掛了，也不影響其它的節點的讀寫，都不需要做故障切換操作，也不會中斷整個集群對外提供的服務。
  • 拓展性優秀，新增節點會自動拉取在線節點的數據（當有新節點加入時，集群會選擇出一個Donor Node為新節點提供數據），最終集群所有節點數據一致，而不需要手動備份恢復。

其劣勢為：

  • 能做到數據的強一致性，毫無疑問，也是以犧牲性能為代價。

PXC原理

PXC集群主要由兩部分組成

PXC集群主要由兩部分組成：

Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一個通用的用於事務型應用的同步、多主復制插件）。

傳統的主從復制

RP即Replication，主從復制。
即只能從主到從進行同步，采用主寫副讀，只有主節點有事務。

1.Master將用戶對數據庫更新的操作以二進制格式保存到 Binary Log日志文件中

2.Slave上面的IO進程連接上Master，並請求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內容;

3.Master接收到來自Slave的IO進程的請求后，通過負責復制的I0進程根據請求信息讀取制定日志指定位置之后的日志信息，返回給 Slave 的IO進程。

返回信息中除了日志所包含的信息之外，還包括本次返回的信息已經到Master端的bin-log文件的名稱以及bin-log的位置;

4.Slave的IO進程接收到信息后，將接收到的日志內容依次添加到Slave端的relay-log文件的最末端，並將讀取到的Master端的bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個bin-log的哪個位置開始往后的日志內容，請發給我”;

5.Slave的Sql進程檢測到relay-log中新增加了內容后，會馬上解析relay-log的內容成為在Master端真實執行時候的那些可執行的內容，並在自身執行。

RP方式下如果主節點沒有同步到從節點，會出現數據不一致性

Replication這種方案不會犧牲性能，但是有個問題就是非強一致性，例如你在DB1中寫入數據可能會因為網絡抖動在DB2中查詢不到數據，這時候客戶端接收到的狀態是已經操作成功。
另外有一點是這種集群方案只能在一個節點中做寫入操作，因為他的底層同步原理是單向同步的。

PXC的副本復制

PXC最大的優勢：強一致性、無同步延遲

圖解：PXC的事務執行流程

在這里插入圖片描述

這里我們用PXC中3個DB節點來介紹其原理，分別是DB1 DB3 和DB3, 數據的同步使用PXC。
先從clent說起 clent在執行insert del update 的時候，正常db1會給我們返回執行的結果，如果我們不提交事務的話是不能持久化到數據庫中的，我們想要真實的持久化就必須要提交事務。

這里在提交事務的時候不僅僅要在當前節點里面持久化數據還要在其他節點持久化數據，畢竟我們是在pxc環境中操作的。

首先在提交事務的時候,db1會把數據傳遞給pxc，pxc會復制當前節點的數據，然后分發給DB2和DB3，分發后要做的就是持久化這些數據。

事務的執行操作在pxc中會生產一個GTID編號，然后由db2 和db3去分別執行這個事務，每個db執行完成后會把結果返回給db1,然后db1收到其他db的執行結果后在本地也執行一下GTID的這個事務，db1執行完成后沒問題的話最終會把執行的結果返回給客戶端。

通過這個時序圖我們可以知道在pxc中的數據強一致，肯定是所有的數據庫中的數據都是一致的。

PXC中重要概念

首先要規范集群中節點的數量，整個集群節點數控制在最少3個、最多8個的范圍內。

最少3個是為了防止腦裂現象，因為只有在兩個節點的情況下才會出現腦裂。腦裂的表現就是輸出任何命令，返回結果都是unkown command。

當一個新節點要加入PXC集群的時候，需要從集群中各節點里選舉出一個doner節點作為全量數據的貢獻者。PXC有兩種節點的數據傳輸方式，一種叫SST全量傳輸，另一種叫IST增量傳輸。

SST:全量同步
IST:增量同步

State Snapshot Transfer(SST) 全量傳輸

Incremental state Transfer(IST)增量傳輸

SST傳輸有XtraBackup、mysqldump、rsync三種方式，而增量傳輸只有XtraBackup。

一般數據量不大的時候可以使用SST作為全量傳輸，但也只使用XtraBackup方式。

節點在集群中，會因新節點的加入或故障，同步失效等而發生狀態的切換，下面列舉出這些狀態的含義：

  • open：節點啟動成功，嘗試連接到集群；
  • primary：節點已在集群中，在新節點加入集群時，選取donor進行數據同步時會產生式的狀態；
  • joiner：節點處於等待接收同步數據文件的狀態；
  • joined：節點已完成了數據同步，嘗試保持和集群中其它節點進度一致；
  • synced：節點正常提供服務的狀態，表示已經同步完成並和集群進度保持一致；
  • doner：節點處於為新加入節點提供全量數據時的狀態；

PXC中重要端口

306:數據庫對外服務的端口號
4444:請求SST(全量同步)，在新節點加入時起做用
4567:組成員之間溝通的端口
4568:傳輸IST(增量同步)，節點下線，重啟加入時起做用

詳解：PXC的執行流程

PXC的操作流程大體是這樣的：

在這里插入圖片描述

說明：圖中的 cb==commit block 提交數據塊

從上圖能夠看出：
當client端執行dml操做時，將操做發給server，server的native進程處理請求。由該server將需要產生的replication writeset廣播出去，然后獲取全局事務ID，一並傳送到其它的節點上去。

這里，有點類似於seata 的原理，具體參見我的分布式事務以及seata 實操視頻。

client端執行commit，server將復制寫數據集發給group(cluster)，cluster 中每一個動做對應一個GTID，其它server接收到並經過驗證(合並數據)后，發現沒有沖突數據，執行appyl_cb動做和commit_cb動做，若沒經過，則會退出處理，就discard此次事務;

而當前節點（客戶端請求的寫入節點）通過驗證之后，執行commit_cb操作，並返回OK給客戶端。如果驗證沒有通過，則rollback_cb。

在生產線上的PXC集群中，至少要有三台節點。

如果其中一個節點沒有驗證通過，出現了數據沖突，那么此時采取的方式就是將出現數據不一致的節點踢出集群，而且它會自動執行shutdown命令來自動關機。

每一個節點都可以讀寫. WriteSet寫的集合，用箱子推給Group里所有的成員， data page 相當於物理復制，而不是發日志,就是一個寫的結果了

用戶發起Commit，在收到Ok之前, 集群每次發起一個動作，都會有一個唯一的編號 , PXC獨有的Global Trx Id
動作發起者: commit_cb, 其它節點多了一個動作： apply_cb

如果主節點寫入過大, apply_cb 時間會不會跟不上, wsrep_slave_threads參數用於解決apply_cb跟不上問題 配置成和CPU的個數相等或是1.5倍，當前節點commit_cb 后就可以返回了。

有關端口

上面的這些事務動作，是通過那個端號交互的？4567

4568 端口 IST(增量同步) 只是在節點下線，重啟加入那一個時間有用。

4444 只會在新節點加入進來時起作用，SST(增量同步)

PXC的啟動關閉流程

State Snapshot Transfer(SST)，每個節點都有一份獨立的數據，當我們用mysql bootstrap-pxc啟動第一個節點，在第一個節點上把帳號初始化，其它節點啟動后加入進來。

集群中有哪些節點是由以下的參數決定：

wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx

第一個節點把自己備份一下(snapshot)傳給加入的新節點，第三個節點的死活是由前兩個節點投票決定。

狀態機變化階段：
1.OPEN: 節點啟動成功，嘗試連接到集群，如果失敗則根據配置退出或創建新的集群
2.PRIMARY: 節點處於集群PC中，嘗試從集群中選取donor進行數據同步
3.JOINER: 節點處於等待接收/接收數據文件狀態，數據傳輸完成后在本地加載數據
4.JOINED: 節點完成數據同步工作，嘗試保持和集群進度一致
5.SYNCED：節點正常提供服務：數據的讀寫，集群數據的同步，新加入節點的sst請求
6.DONOR(貢獻數據者)：節點處於為新節點准備或傳輸集群全量數據狀態，對客戶端不可用。

img

狀態機變化因素：
1.新節點加入集群
2.節點故障恢復
3.節點同步失效

第一個節點啟動

當我們啟動第一個節點， bootstrap-pxc
當前集群沒有其它成員，你就是老大了。

新啟動的節點的狀態-> open ->primary

在第一個節點上可以把帳號初始化， 基本初始化，都搞定了。
初始化的時間，隨便那個節點都可以。

其他節點加入

其它節點再起來就是要加入進來的。

wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx

新啟動的節點的狀態-> open ->primary -> joiner

你是新成員，你沒有ID，第一個節點 把自已備份一下（snapshot) 傳給加入的新節點： SST

傳輸SST有幾種方法:

mysqldump

xtrabackup

rsync

停機重啟后增量同步

當node3停機重啟后，通過IST來同步增量數據，來完成保證與node1和node2的數據一致，

IST的實現是由wsrep_provider_options="gcache.size=1G"參數決定，一般設置為1G大，參數大小是由什么決定的，根據停機時間，若停機一小時，需要確認1小時內產生多大的binlog來算出參數大小。

避免全部SST

假設我們三個節點都關閉了，會發生什么呢

全部傳SST，因為gcache數據沒了

全部關閉需要采用滾動關閉方式：

1． 關閉node1，修復完后，啟動加回來;

2． 關閉node2,修復完后，啟動加回來;

3． ………………….,直到最后一個節點

4． 原則要保持Group里最少一個成員活着

數據庫關閉之后，最會保存一個last Txid，所以啟動時，先要啟動最后一個關閉的節點。

總之：啟動順序和關閉順序剛好相反。

wsrep_recover=on參數在啟動時加入，用於從log中分析gtid。

怎樣避免關閉和啟動時數據丟失？

  1. 所有的節點中最少有一個在線，進行滾動重啟;

  2. 利用主從的概念，把一個從節點轉化成PXC里的節點。

PXC的分布式系統CAP類型

分布式系統的CAP理論：
C：一致性，所有的節點數據一致
A：可用性，一個或者多個節點失效，不影響服務請求
P：分區容忍性，節點間的連接失效，仍然可以處理請求
其實，任何一個分布式系統，需要滿足這三個中的兩個。

PXC屬於CP類型

強一致性的話可以用來保存一些有價值的數據例如訂單，支付等。

pxc 采用的是同步復制，事務在所有集群中要么全提交要么不提交，保證了數據的一致性。它寫入數據速度慢

使用場景：

pxc方案存儲高價值數據，如：賬戶、訂單、交易數據等..

RP屬於AP

非強一致性方案可以用來保存用戶的操作或者用戶行為瀏覽等數據。

replication 采用的是異步復制，無法保證數據的一致性。它寫入數據速度快。

使用場景：

replication方案存儲低價值數據，如：通知、日志等..

PXC高可用集群方案

這樣一個最基本的PXC集群，它保證了每個節點的的數據都是一致的，

不會出現數據寫入了數據庫1而沒有寫入數據庫2的情況，這種的集群在遇到單表數據量超過2000萬的時候，mysql性能會受損，所以一個集群還不夠.

img

數據切片

我們需要把數據分到另一個集群，這個稱為“切片”，就是把大量的數據拆分到不同的集群中，每個集群的數據都是不一樣的

看下面的截圖：

img

這樣一來，PXC集群1存前面1000萬條數據，PXC集群2存后面1000萬條數據

，當一個sql語句請求的時候，通過MyCat這個阿里巴巴的開源中間件，可以把sql分到不同的集群里面去。這種的分片按照數量就是2個分片。

這個切分算法也比較多，比如按照日期、月份、年份、某一列的固定值，或者最簡單的按照主鍵值切分，主鍵對2求模，余0的存分片1，余1的存分片2，這樣MyCat就會把2000萬條數據均勻地分配到2個集群上。

PXC雖然保證了數據的強一致性，但是這是以犧牲性能為代價的，所以適合保存重要的數據，比如訂單。

shardingJdbc

使用shardingJdbc，也是一樣的，推薦使用sharding jdbc，具體請看我的 10Wqps架構視頻

在這里插入圖片描述

在這里插入圖片描述

Replication集群方案

img

這種集群，在第一個節點插入以后，就馬上返回給客戶端執行成功了，然后再做每個節點之間的同步，如果某一個同步操作失敗了，那用戶請求的時候拿到的數據就不同步了，但是它的優勢是速度快，不會犧牲任何地性能，適合保存不那么重要的數據，比如日志。

PXC與Replication集群結合

img

使用shardingJdbc，也是一樣的，推薦使用sharding jdbc，具體請看我的 10Wqps架構視頻

在這里插入圖片描述

PXC優缺點

優點：

1）同步復制，事務要么在所有節點提交或不提交。

2）多主復制，可以在任意節點進行寫操作。 由於是多節點寫入，所以DB故障切換很容易。完成了真正的多節點讀寫的集群方案；

3）在從服務器上並行應用事件，真正意義上的並行復制。 改善了主從復制延遲問題，基本上達到了實時同步；

4）節點自動配置，數據一致性，不再是異步復制。 新加入的節點可以自動部署，無需提交手動備份，維護方便；

PXC最大的優勢：強一致性、實現了MySQL集群的高可用性和數據的強一致性；無同步延遲。

缺點：

加入新節點時開銷大。

添加新節點時，必須從現有節點之一復制完整數據集。如果是100GB，則復制100GB。
任何更新的事務都需要全局驗證通過，才會在其他節點上執行，集群性能受限於性能最差的節點，也就說常說的木桶定律。

鎖沖突的問題

因為需要保證數據的一致性，PXC采用的實時基於存儲引擎層來實現同步復制，所以在多節點並發寫入時，鎖沖突問題比較嚴重。

寫擴大的問題

存在寫擴大的問題。所以節點上都會發生寫操作，對於寫負載過大的場景，不推薦使用PXC。

生成的ID不連續

在PXC中，生成的ID有可能是不連續的，如果期望連續就需要將ID生成策略提高一級，比如放在數據切分中間件中，如mycat等。

或者在程序中執行ID的賦予問題。

腦裂問題

PXC集群數量建議為奇數，防止腦裂。

任何命令執行出現unkown command ，表示出現腦裂，集群兩節點間4567端口連不通，無法提供對外服務。

並發寫

三個節點的自增起始值為1、2、3，步長都為3，解決了insert問題，但update同時對一行操作就會有問題，出現：Error： 1213SQLSTATE: 40001，所以更新和寫入在一個節點上操作。

pxc結構里面必須有主鍵

如果沒有主建，有可能會造成集中每個節點的Data page里的數據不一樣

不支持表級鎖

不支持lock /unlock tables

不支持XA事務

這點可以使用seaa

性能符合水桶原理

性能由集群中性能最差的節點決定

參考文獻：

https://www.cnblogs.com/peng-zone/p/11676678.html#pxc原理圖

http://www.percona.com/

https://mariadb.org/

https://www.jianshu.com/p/47054c12afa7

​


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 Redis集群 - 圖解 - 秒懂（史上最全) elasticsearch高可用 HA原理 (圖解+秒懂+史上最全) Docker底層原理（圖解+秒懂+史上最全） DNS圖解（秒懂 - 史上最全） CDN圖解（秒懂 + 史上最全） Java NIO （圖解+秒懂+史上最全） MappedByteBuffer 詳解（圖解+秒懂+史上最全） Kafka源碼分析9：Controller控制器的原理（圖解+秒懂+史上最全） nginx keepalive 高可用 原理和實操 （圖解+秒懂+史上最全） Kafka源碼分析9：Controller控制器的原理（圖解+秒懂+史上最全）
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM