MySQL叢集常見高可用方案（轉）
版權宣告：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/ZYC88888/article/details/81287951 1. 概述
我們在考慮MySQL資料庫的高可用的架構時，主要要考慮如下幾方面：
如果資料庫發生了宕機或者意外中斷等故障，能儘快恢復資料庫的可用性，儘可能的減少停機時間，保證業務不會因為資料庫的故障而中斷。 用作備份、只讀副本等功能的非主節點的資料應該和主節點的資料實時或者最終保持一致。 當業務發生資料庫切換時，切換前後的資料庫內容應當一致，不會因為資料缺失或者資料不一致而影響業務。 關於對高可用的分級在這裡我們不做詳細的討論，這裡只討論常用高可用方案的優缺點以及高可用方案的選型。
2. 高可用方案
2.1. 主從或主主半同步複製
使用雙節點資料庫，搭建單向或者雙向的半同步複製。在5.7以後的版本中，由於lossless replication、logical多執行緒複製等一些列新特性的引入，使得MySQL原生半同步複製更加可靠。
常見架構如下：
通常會和proxy、keepalived等第三方軟體同時使用，即可以用來監控資料庫的健康，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用資料庫。
優點：
架構比較簡單，使用原生半同步複製作為資料同步的依據； 雙節點，沒有主機宕機後的選主問題，直接切換即可； 雙節點，需求資源少，部署簡單； 缺點：
完全依賴於半同步複製，如果半同步複製退化為非同步複製，資料一致性無法得到保證； 需要額外考慮haproxy、keepalived的高可用機制。 2.2. 半同步複製優化
半同步複製機制是可靠的。如果半同步複製一直是生效的，那麼便可以認為資料是一致的。但是由於網路波動等一些客觀原因，導致半同步複製發生超時而切換為非同步複製，那麼這時便不能保證資料的一致性。所以儘可能的保證半同步複製，便可提高資料的一致性。
該方案同樣使用雙節點架構，但是在原有半同複製的基礎上做了功能上的優化，使半同步複製的機制變得更加可靠。
可參考的優化方案如下：
2.2.1. 雙通道複製
半同步複製由於發生超時後，複製斷開，當再次建立起復制時，同時建立兩條通道，其中一條半同步複製通道從當前位置開始複製，保證從機知道當前主機執行的進度。另外一條非同步複製通道開始追補從機落後的資料。當非同步複製通道追趕到半同步複製的起始位置時，恢復半同步複製。
2.2.2. binlog檔案伺服器
搭建兩條半同步複製通道，其中連線檔案伺服器的半同步通道正常情況下不啟用，當主從的半同步複製發生網路問題退化後，啟動與檔案伺服器的半同步複製通道。當主從半同步複製恢復後，關閉與檔案伺服器的半同步複製通道。
優點：
雙節點，需求資源少，部署簡單； 架構簡單，沒有選主的問題，直接切換即可; 相比於原生複製，優化後的半同步複製更能保證資料的一致性。 缺點：
需要修改核心原始碼或者使用mysql通訊協議。需要對原始碼有一定的瞭解，並能做一定程度的二次開發。 依舊依賴於半同步複製，沒有從根本上解決資料一致性問題。 2.3. 高可用架構優化
將雙節點資料庫擴充套件到多節點資料庫，或者多節點資料庫叢集。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的叢集。
由於半同步複製，存在接收到一個從機的成功應答即認為半同步複製成功的特性，所以多從半同步複製的可靠性要優於單從半同步複製的可靠性。並且多節點同時宕機的機率也要小於單節點宕機的機率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。
但是由於資料庫數量較多，所以需要資料庫管理軟體來保證資料庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：
2.3.1. MHA+多節點叢集
MHA Manager會定時探測叢集中的master節點，當master出現故障時，它可以自動將最新資料的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程式完全透明。
MHA Node執行在每臺MySQL伺服器上，主要作用是切換時處理二進位制日誌，確保切換儘量少丟資料。
MHA也可以擴充套件到如下的多節點叢集：
優點：
可以進行故障的自動檢測和轉移; 可擴充套件性較好，可以根據需要擴充套件MySQL的節點數量和結構; 相比於雙節點的MySQL複製，三節點/多節點的MySQL發生不可用的概率更低 缺點：
至少需要三節點，相對於雙節點需要更多的資源; 邏輯較為複雜，發生故障後排查問題，定位問題更加困難; 資料一致性仍然靠原生半同步複製保證，仍然存在資料不一致的風險; 可能因為網路分割槽發生腦裂現象; 2.3.2. zookeeper+proxy
Zookeeper使用分散式演算法保證叢集資料的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網路分割槽現象的產生。
優點：
較好的保證了整個系統的高可用性，包括proxy、MySQL; 擴充套件性較好，可以擴充套件為大規模叢集; 缺點：
資料一致性仍然依賴於原生的mysql半同步複製; 引入zk，整個系統的邏輯變得更加複雜; 2.4. 共享儲存
共享儲存實現了資料庫伺服器和儲存裝置的解耦，不同資料庫之間的資料同步不再依賴於MySQL的原生複製功能，而是通過磁碟資料同步的手段，來保證資料的一致性。
2.4.1. SAN共享儲存
SAN的概念是允許儲存裝置和處理器（伺服器）之間建立直接的高速網路（與LAN相比）連線，通過這種連線實現資料的集中式儲存。常用架構如下：
使用共享儲存時，MySQL伺服器能夠正常掛載檔案系統並操作，如果主庫發生宕機，備庫可以掛載相同的檔案系統，保證主庫和備庫使用相同的資料。
優點：
兩節點即可，部署簡單，切換邏輯簡單； 很好的保證資料的強一致性； 不會因為MySQL的邏輯錯誤發生資料不一致的情況； 缺點：
需要考慮共享儲存的高可用； 價格昂貴； 2.4.2. DRBD磁碟複製
DRBD是一種基於軟體、基於網路的塊複製儲存解決方案，主要用於對伺服器之間的磁碟、分割槽、邏輯卷等進行資料映象，當用戶將資料寫入本地磁碟時，還會將資料傳送到網路中另一臺主機的磁碟上，這樣的本地主機(主節點)與遠端主機(備節點)的資料就可以保證實時同步。常用架構如下：
當本地主機出現問題，遠端主機上還保留著一份相同的資料，可以繼續使用，保證了資料的安全。
DRBD是linux核心模組實現的快級別的同步複製技術，可以與SAN達到相同的共享儲存效果。
優點：
兩節點即可，部署簡單，切換邏輯簡單； 相比於SAN儲存網路，價格低廉； 保證資料的強一致性； 缺點：
對io效能影響較大； 從庫不提供讀操作； 2.5. 分散式協議
分散式協議可以很好解決資料一致性問題。比較常見的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方叢集的部署方案，通過使用NDB儲存引擎實時備份冗餘資料，實現資料庫的高可用性和資料一致性。
優點：
全部使用官方元件，不依賴於第三方軟體； 可以實現資料的強一致性； 缺點：
國內使用的較少； 配置較複雜，需要使用NDB儲存引擎，與MySQL常規引擎存在一定差異； 至少三節點； 2.5.2. Galera
基於Galera的MySQL高可用叢集， 是多主資料同步的MySQL叢集解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：
優點：
多主寫入，無延遲複製，能保證資料強一致性； 有成熟的社群，有網際網路公司在大規模的使用； 自動故障轉移，自動新增、剔除節點； 缺點：
需要為原生MySQL節點打wsrep補丁 只支援innodb儲存引擎 至少三節點； 2.5.3. POAXS
Paxos 演算法解決的問題是一個分散式系統如何就某個值（決議）達成一致。這個演算法被認為是同類演算法中最有效的。Paxos與MySQL相結合可以實現在分散式的MySQL資料的強一致性。常見架構如下
優點：
多主寫入，無延遲複製，能保證資料強一致性； 有成熟理論基礎； 自動故障轉移，自動新增、剔除節點； 缺點：
只支援innodb儲存引擎 至少三節點； 3. 總結
隨著人們對資料一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分散式資料一致性的問題，如MySQL自身的優化、MySQL叢集架構的優化、Paxos、Raft、2PC演算法的引入等等。
而使用分散式演算法用來解決MySQL資料庫資料一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規模使用。
隨著官方MySQL Group Replication的GA，使用分散式協議來解決資料一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。
參考文獻
[2015 OTN]彭立勳-DoubleBinlog方案.pdf
參考：
https://zhuanlan.zhihu.com/p/25960208（以上內容轉自此篇文章）
使用磁碟技術徹底解決mysql叢集架構，使用了GFS2，但暫時無法解決磁碟I/O問題；使用了GlusterFS，發現又不建議伺服器長時間保持開機狀態下使用，DRDB也只能解決mysql的高可用問題，又考慮到負載，考慮到成本，所以最後還是需要配合使用，詢問同行朋友，大多數公司都是下列架構；
做讀寫分離，通過mysql自帶的同步方案replication實現資料同步，使用分散式檔案系統切換關鍵節點，解決單點問題；
下文僅供參考，借鑑而來，具體配置，後續釋出；
1、mysql企業常用叢集架構
在中小型網際網路的企業中。mysql的叢集一般就是上圖的架構。WEB節點讀取資料庫的時候讀取dbproxy伺服器。dbproxy伺服器通過對SQL語句的判斷來進行資料庫的讀寫分離。讀請求負載到從庫（也可以把主庫加上），寫請求寫主庫。
這裡的dbproxy是資料庫叢集的唯一出口所以也需要做高可用。
drproxy是資料庫讀寫分離的常用軟體，amoeba、mycat、cobar也很常用。這類軟體不僅帶有讀寫分離功能，還可以實現負載均衡以及後端節點的健康檢查。
資料庫的讀寫分離除了通過這類資料庫中介軟體軟體實現，還可以寫在程式中。
通常我們的主庫要做雙主高可用，實現主庫掛掉另一個主庫立刻接管。如果不做雙主，從庫接管主庫的時候需要做狀態遷移，會有延遲。
資料庫主庫的高可用重點需要考慮的是資料同步。比較常用的高可用方案有：
1、keepalived+mysql replication。通過keepalived實現VIP飄逸，通過mysql自帶的同步方案replication實現資料同步。
2、hearbeat+drbd。通過drbd實現雙主資料的同步，這個資料同步是基於塊裝置的。比一般的同步方案要快很多。通過heartbeat實現VIP漂移以及drbd資源的切換管理。
3、keepalived+mha。
對於從庫，最好不要超過5個。我們可以把其中的三個作為使用者訪問的節點，把另外一個作為內部人員的查詢節點。因為內部人員查詢節點的時候一般是按照時間段查詢，不經過索引，佔用的資源比較多，所以要把這個節點單獨專用，以免影響客戶訪問。最後我們應該留一個從庫進行資料庫的資料備份。
從庫的資料一致性保持可以通過直接於主庫進行主從輔助，也可以從其他從庫那進行主從複製（優點是減少主庫壓力，缺點是延遲稍大）。
2、MYSQL資料架構
資料庫伺服器==》資料庫（多個例項）==》多個庫==》多個表==》多個欄位行列（資料）
在一臺資料庫伺服器上可以跑多個例項，一個例項中有多個庫，一個庫有多個表，一個表有多個行列。
作者：宇信智臻sy 連結：https://www.jianshu.com/p/5d522a068fa9 來源：簡書 簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。 --------------------- 作者：ZhaoYingChao88 來源：CSDN 原文：https://blog.csdn.net/ZYC88888/article/details/81287951 版權宣告：本文為博主原創文章，轉載請附上博文連結！