零、為什么需要群集？
在現在的科技環境下，我們的項目中往往會處理越來越多的數據量，隨着數據量的遞增，單一的數據庫已經無法滿足我們的業務要求，因此為了解決這一系列的數據庫瓶頸，我們有了集群的搭建方案。
一、MySQL版本
引擎對比：
1、myisam沒有事務支持
MariaDB針對MyISAM改進，Aria占用空間小，並且允許在系統之間輕松進行復制。
2、innodb提供事務支持，innodb在做任何操作時，會做一個日志操作，便於恢復。
它是MariaDB 10.2（以及MySQL）的默認存儲引擎。
3、xtradb是innodb存儲引擎的增強版本，擁有更高性能。
MariaDB在10.0.9版本起使用XtraDB來代替MySQL的InnoDB。
在MariaDB 10.1之前XtraDB是最佳選擇，它是InnoDB的性能增強分支，並且是MariaDB 10.1之前的默認引擎。
版本對比：
1、Percona提供了高性能XtraDB引擎，還提供了PXC高可用解決方案，並且附帶了percona-toolkit等DBA管理工具箱。
2、MariaDB在10.2.6版本里移除Percona XtraDB，換回默認InnoDB，現在10.5默認是InnoDB。
綜合多年使用經驗和性能對比，首選Percona分支，其次是MariaDB，如果你不想冒險，那就選擇MYSQL官方版本。推薦MariaDB
二、Mysql群集方案
方案一：共享存儲
一般共享存儲采用比較多的是 SAN/NAS 方案。
SAN：共享存儲，主庫從庫用的一個存儲。SAN的概念是允許存儲設施和解決器（服務器）之間建立直接的高速連接，通過這種連接實現數據的集中式存儲。
優點：
1、保證數據的強一致性；
2、與mysql解耦，不會由於mysql的邏輯錯誤發生數據不一致的情況；
缺點：
1、SAN價格昂貴；
方案二：操作系統實時數據塊復制
這個方案的典型場景是 DRBD，DRBD架構(MySQL+DRBD+Heartbeat)
DRDB：這是linux內核板塊實現的快級別的同步復制技術。通過各主機之間的網絡，復制對方磁盤的內容。當客戶將數據寫入本地磁盤時，還會將數據發送到網絡中另一台主機的磁盤上，這樣的本地主機(主節點)與遠程主機(備節點)的數據即可以保證明時同步。
優點：
1、相比於SAN儲存網絡，價格低廉；
2、保證數據的強一致性；
3、與mysql解耦，不會由於mysql的邏輯錯誤發生數據不一致的情況；
缺點：
1、對io性能影響較大；
2、從庫不提供讀操作；
方案三：主從復制架構
單點模式、主備模式、主從模式
單點模式：
單點模式是最簡單的單機模式，只有一台數據庫服務器，部署最簡單。但是存在單點風險，一旦這台服務器掛掉，整個系統也就掛掉了。
主備模式：
為了解決單點模式的風險，主備模式產生。目前，主備模式應該是各個線上服務系統的最低配置了，比如你在各個雲平台購買的數據庫服務一般都會開啟備份功能。一旦主節點出現問題，還可以切換到備份節點，不至於整個系統癱瘓。
主備又分為一主一備、一主多備。多個備份是為了保證更高的安全性，萬一主節點出現問題的時候，碰巧備份節點也出問題呢。
當主節點出現問題的時候要切換到備份節點，切換方式又分為手動切換和自動切換。手動切換具有一定的延時，當主節點出現問題時，只能等運維人員發現或者收到系統通知。
主從模式：
主從配置一般都是和讀寫分離相結合，主服務器負責寫數據，從服務器負責讀數據，並保證主服務器的數據及時同步到從服務器。
主從模式又分為一主一從、一主多從和多主多從，越往后部署越復雜，同時，系統穩定性更高。主從模式可以更好的分擔數據庫壓力，將插入更新操作和查詢操作分開，提高系統整體性能。
架構一、主從復制(一主多從)
架構二、MMM架構(雙主多從 Master-Master replication manager for Mysql)
MMM，全稱為Master-Master replication manager for Mysql，是一套支持雙主故障切換和雙主日常管理的腳本程序，MMM使用Perl語言開發。主要用來監控和管理MySQL Master-Master(雙)復制。特別適合DBA做維護等需要主從復制的場景，通過雙主架構避免了重復搭建從庫的麻煩。雖然叫做雙主復制，但是業務上同一時刻只允許對一個主進行寫入，另一台備選主上提供部分讀服務，以加速在主主切換時備選主的預熱。
MMM優缺點
優點：
1、高可用性，擴展性好，出現故障自動切換，對於主主同步，在同一時間只提供一台數據庫寫操作，保證的數據的一致性。
2、自動的主主Failover切換，一般3s以內切換備機
3、多個Slave讀的負載均衡。
缺點：
1、無法完全保證數據的一致性（在db1宕機過程中，一旦db2落后於db1,這時發生切換，db2變成了可寫狀態，數據的一致性就無法保證）
2、無論何時，只有一個數據庫可寫；db1宕機后，write VIP會指向db2，當db1恢復后，db1不會自動變成可寫主，需要手動move_role 或者db2宕機。所以read host要包括db1，不然容易造成浪費；
3、由於是使用虛擬IP浮動技術，類似Keepalived，故RIP（真實IP）要和VIP（虛擬IP）在同一網段；如果是在不同網段也可以，需要用到虛擬路由技術。
4、Monitor節點是單點，可以結合Keepalived實現高可用。
架構三、MHA架構(多主多從 Master High Availability Manager and Toolsfor MySQL)
目前在Mysql高可用方面是一個相對成熟的解決方案。它是日本的一位MySQL專家采用Perl語言編寫的一個腳本管理工具，該工具僅適用於MySQLReplication 環境，目的在於維持Master主庫的高可用性。
MHA優缺點：
優點：
1、自動監控Master故障轉移、故障后節點之間的數據同步
2、不會有性能損耗，適用於任何存儲引擎
3、具備自動數據補償能力，在主庫異常崩潰時能夠最大程度的保證數據的一致性
4、可實現同城應用級別雙活
5、最大程度上保證數據的一致性
缺點：
1、MHA架構實現讀寫分離，最佳實踐是在應用開發設計時提前規划讀寫分離事宜，在使用時設置兩個連接池，即讀連接池與寫連接池，也可以選擇折中方案即引入SQL Proxy。但無論如何都需要改動代碼；
2、關於讀負載均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能實現負載均衡、故障檢查及備升級為主后的讀寫剝離功能即可，建議使用LVS；
3、MHA Manager Node 主要負責主庫在crash時將bin log完整同步到slave庫、監控主備庫的狀態及切換。
方案四：數據庫高可用架構
這種方式比較經典的案例包括 MGR(MySQL Group Replication)和 Galera 等，最近業內也有一些類似的嘗試，如使用一致性協議算法，自研高可用數據庫的架構等。
1.MGR(MySQL Group Replication，MySQL官方開發的一個實現MySQL高可用集群的一個工具。第一個GA版本正式發布於MySQL5.7.17中)
MGR是基於現有的MySQL架構實現的復制插件，可以實現多個主對數據進行修改，使用paxos協議復制，不同於異步復制的多Master復制集群。
支持多主模式，但官方推薦單主模式：
1、多主模式下，客戶端可以隨機向MySQL節點寫入數據
2、單主模式下，MGR集群會選出primary節點負責寫請求，primary節點與其它節點都可以進行讀請求處理.
優點：
1、基本無延遲，延遲比異步的小很多
2、支持多寫模式，但是目前還不是很成熟
3、數據的強一致性，可以保證數據事務不丟失
缺點:
1、僅支持innodb
2、只能用在GTID模式下，且日志格式為row格式
適用的業務場景：
1、對主從延遲比較敏感
2、希望對對寫服務提供高可用，又不想安裝第三方軟件
3、數據強一致的場景
讀寫負載大問題
讀負載大：
1、增加slave
2、加中間層(MyCat，ProxySQL，Maxscale)
3、讀寫分離
關於寫負載大：
1、分庫分表
2、增加中間層
2.Galera
方案五：MySQL Cluster和PXC
MySQL Cluster(ndb存儲引擎，比較復雜，業界並沒有大規模使用)
PXC(Percona XtraDB Cluster)
RXC方案與Replication方案的對比
RXC采用同步復制，事務在所有集群節點要么同時提交，要么不提交
Replication采用異步復制，無法保證數據的一致性
三、常用方案：
目前大多公司目前采用的有三種，PXC，MHA，MGR，MySQL5.6版本的采用MHA，5.7版本的采用MGR。注：所以mysql版本最好在5.7或8.0版本以上
MGR是基於現有的MySQL架構實現的復制插件，可以實現多個主對數據進行修改，使用paxos協議復制，不同於異步復制的多Master復制集群。
支持多主模式，但官方推薦單主模式：
多主模式下，客戶端可以隨機向MySQL節點寫入數據
單主模式下，MGR集群會選出primary節點負責寫請求，primary節點與其它節點都可以進行讀請求處理.