# 多圖文，詳細介紹mysql各個叢集方案 叢集的好處 - 高可用性：故障檢測及遷移，多節點備份。 - 可伸縮性：新增資料庫節點便利，方便擴容。 - 負載均衡：切換某服務訪問某節點，分攤單個節點的資料庫壓力。 叢集要考慮的風險 - 網路分裂：群集還可能由於網路故障而拆分為多個部分，每部分內的節點相互連線，但各部分之間的節點失去連線。 - 腦裂：導致資料庫節點彼此獨立執行的叢集故障稱為“腦裂”。這種情況可能導致資料不一致，並且無法修復，例如當兩個資料庫節點獨立更新同一表上的同一行時。 @[toc] ### 一，mysql原廠出品 ##### 1，MySQL Replication mysql複製（MySQL Replication），是mysql自帶的功能。 原理簡介： 主從複製是通過重放binlog實現主庫資料的非同步複製。即當主庫執行了一條sql命令，那麼在從庫同樣的執行一遍，從而達到主從複製的效果。在這個過程中，master對資料的寫操作記入二進位制日誌檔案中(binlog)，生成一個 log dump 執行緒，用來給從庫的 i/o執行緒傳binlog。而從庫的i/o執行緒去請求主庫的binlog，並將得到的binlog日誌寫到中繼日誌（relaylog）中，從庫的sql執行緒，會讀取relaylog檔案中的日誌，並解析成具體操作，通過主從的操作一致，而達到最終資料一致。  MySQL Replication一主多從的結構，主要目的是實現資料的多點備份（沒有故障自動轉移和負載均衡）。相比於單個的mysql，一主多從下的優勢如下： - 如果讓後臺讀操作連線從資料庫，讓寫操作連線主資料庫，能起到讀寫分離的作用，這個時候多個從資料庫可以做負載均衡。 - 可以在某個從資料庫中暫時中斷複製程序，來備份資料，從而不影響主資料的對外服務（如果在master上執行backup，需要讓master處於readonly狀態，這也意味這所有的write請求需要阻塞）。 就各個叢集方案來說，其優勢為： - 主從複製是mysql自帶的，無需藉助第三方。 - 資料被刪除，可以從binlog日誌中恢復。 - 配置較為簡單方便。 其劣勢為： - 從庫要從binlog獲取資料並重放，這肯定與主庫寫入資料存在時間延遲，因此從庫的資料總是要滯後主庫。 - 對主庫與從庫之間的網路延遲要求較高，若網路延遲太高，將加重上述的滯後，造成最終資料的不一致。 - 單一的主節點掛了，將不能對外提供寫服務。 ##### 2，MySQL Fabirc mysql織物（MySQL Fabirc），是mysql官方提供的。 這是在MySQL Replication的基礎上，增加了故障檢測與轉移，自動資料分片功能。不過依舊是一主多從的結構，MySQL Fabirc只有一個主節點，區別是當該主節點掛了以後，會從從節點中選擇一個來當主節點。 就各個叢集方案來說，其優勢為： - mysql官方提供的工具，無需第三方外掛。 - 資料被刪除，可以從binlog日誌中恢復。 - 主節點掛了以後，能夠自動從從節點中選擇一個來當主節點，不影響持續對外提供寫服務。 其劣勢為： - 從庫要從binlog獲取資料並重放，這肯定與主庫寫入資料存在時間延遲，因此從庫的資料總是要滯後主庫。 - 對主庫與從庫之間的網路延遲要求較高，若網路延遲太高，將加重上述的滯後，造成最終資料的不一致。 - 2014年5月推出的產品，資料庫資歷較淺，應用案例不多，網上各種資料相對較少。 - 事務及查詢只支援在同一個分片內，事務中更新的資料不能跨分片，查詢語句返回的資料也不能跨分片。 - 節點故障恢復30秒或更長（採用InnoDB儲存引擎的都這樣）。 ##### 3，MySQL Cluster mysql叢集（MySQL Cluster）也是mysql官方提供的。 MySQL Cluster是多主多從結構的 就各個叢集方案來說，其優勢為： - mysql官方提供的工具，無需第三方外掛。 - 高可用性優秀，99.999%的可用性，可以自動切分資料，能跨節點冗餘資料（其資料集並不是儲存某個特定的MySQL例項上，而是被分佈在多個Data Nodes中，即一個table的資料可能被分散在多個物理節點上，任何資料都會在多個Data Nodes上冗餘備份。任何一個數據變更操作，都將在一組Data Nodes上同步，以保證資料的一致性）。 - 可伸縮性優秀，能自動切分資料，方便資料庫的水平拓展。 - 負載均衡優秀，可同時用於讀操作、寫操作都都密集的應用，也可以使用SQL和NOSQL介面訪問資料。 - 多個主節點，沒有單點故障的問題，節點故障恢復通常小於1秒。 其劣勢為： - 架構模式和原理很複雜。 - 只能使用儲存引擎 NDB ，與平常使用的InnoDB 有很多明顯的差距。比如在事務（其事務隔離級別只支援Read Committed，即一個事務在提交前，查詢不到在事務內所做的修改），外來鍵（雖然最新的NDB 儲存引擎已經支援外來鍵，但效能有問題，因為外來鍵所關聯的記錄可能在別的分片節點），表限制上的不同，可能會導致日常開發出現意外。[點選檢視具體差距比較](https://dev.mysql.com/doc/mysql-cluster-excerpt/8.0/en/mysql-cluster-ndb-innodb-engines.html) - 作為分散式的資料庫系統，各個節點之間存在大量的資料通訊，比如所有訪問都是需要經過超過一個節點（至少有一個 SQL Node和一個 NDB Node）才能完成，因此對節點之間的內部網際網路絡頻寬要求高。 - Data Node資料會被儘量放在記憶體中，對記憶體要求大，而且重啟的時候，資料節點將資料load到記憶體需要很長時間。 官方的三兄弟的區別對比如下圖所示；  ### 二，mysql第三方優化 ##### 4，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機房組建叢集。 ##### 5，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 ##### 6，Galera Cluster Galera Cluster是由Codership開發的MySQL多主結構叢集，這些主節點互為其它節點的從節點。不同於MySQL原生的主從非同步複製，Galera採用的是多主同步複製，並針對同步複製過程中，會大概率出現的事務衝突和死鎖進行優化，就是複製不基於官方binlog而是Galera複製外掛，重寫了wsrep api。 > 非同步複製中，主庫將資料更新傳播給從庫後立即提交事務，而不論從庫是否成功讀取或重放資料變化。這種情況下，在主庫事務提交後的短時間內，主從庫資料並不一致。 > > 同步複製時，主庫的單個更新事務需要在所有從庫上同步 更新。換句話說，當主庫提交事務時，叢集中所有節點的資料保持一致。 對於讀操作，從每個節點讀取到的資料都是相同的。對於寫操作，當資料寫入某一節點後，叢集會將其同步到其它節點。  就各個叢集方案來說，其優勢為： - 多主多活下，可對任一節點進行讀寫操作，就算某個節點掛了，也不影響其它的節點的讀寫，都不需要做故障切換操作，也不會中斷整個叢集對外提供的服務。 - 拓展性優秀，新增節點會自動拉取線上節點的資料（當有新節點加入時，叢集會選擇出一個Donor Node為新節點提供資料），最終叢集所有節點資料一致，而不需要手動備份恢復。 其劣勢為： - 能做到資料的強一致性，毫無疑問，也是以犧牲效能為代價。 ### 三，依託硬體配合 不同主機的資料同步不再依賴於MySQL的原生複製功能，而是通過同步磁碟資料，來保證資料的一致性。 然後處理故障的方式是藉助Heartbeat，它監控和管理各個節點間連線的網路，並監控叢集服務，當節點出現故障或者服務不可用時，自動在其他節點啟動叢集服務。 ##### 7，heartbeat+SAN SAN：共享儲存，主庫從庫用的一個儲存。SAN的概念是允許儲存設施和解決器（伺服器）之間建立直接的高速連線，通過這種連線實現資料的集中式儲存。  就各個叢集方案來說，其優勢為： - 保證資料的強一致性； - 與mysql解耦，不會由於mysql的邏輯錯誤發生資料不一致的情況； 其劣勢為： - SAN價格昂貴； ##### 8，heartbeat+DRDB DRDB：這是linux核心板塊實現的快級別的同步複製技術。通過各主機之間的網路，複製對方磁碟的內容。當客戶將資料寫入本地磁碟時，還會將資料傳送到網路中另一臺主機的磁碟上，這樣的本地主機(主節點)與遠端主機(備節點)的資料即可以保證明時同步。  就各個叢集方案來說，其優勢為： - 相比於SAN儲存網路，價格低廉； - 保證資料的強一致性； - 與mysql解耦，不會由於mysql的邏輯錯誤發生資料不一致的情況； 其劣勢為： - 對io效能影響較大； - 從庫不提供讀操作； ### 四，其它 ##### 9，Zookeeper + proxy Zookeeper使用分散式演算法保證叢集資料的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網路分割槽現象的產生。  就各個叢集方案來說，其優勢為： - 擴充套件性較好，可以擴充套件為大規模叢集。 缺其劣勢為： - 搭建Zookeeper 叢集，在配置一套代理，整個系統的邏輯變得更加複雜。 ##### 10，Paxos 分散式一致性演算法，Paxos 演算法處理的問題是一個分散式系統如何就某個值（決議）達成一致。這個演算法被認為是同類演算法中最有效的。Paxos與MySQL相結合可以實現在分散式的MySQL資料的強一致性。 ![Paxos_lgx211](https://img-blog.csdnimg.cn/20200310170035997.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzc1MDIxMg==,size_16,color_FFFFF