MySQL-高可用架构探索
文章目錄
- 生猛干貨
- 官方文檔
- 前置學習
- 什么是高可用( HA - High Availability )
- 實現高可用的幾點原則
- 避免MySQL單點故障的幾種方案
- 使用SUN共享存儲
- 使用DRDB磁盤復制
- 使用用多寫集群（PXC方案）
- 使用NDB集群
- 使用MySQL的主從復制
- MMM （Multi-Master Replication Manager ）
- MMM的主要作用
- MMM提供的功能
- MMM架構圖
- MMM部署需要的資源
- MMM架構安裝和部署
- MMM架構的優缺點
- MHA （Master High Availability）
- 架構
- MHA提供的功能
- MHA主從切換過程
- MHA配置的步驟
- MHA的安裝和部署
- MHA的優缺點
- 搞定MySQL
生猛干貨
帶你搞定MySQL實戰，輕松對應海量業務處理及高并發需求，從容應對大場面試
官方文檔
https://dev.mysql.com/doc/
如果英文不好的話，可以參考 searchdoc 翻譯的中文版本
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
前置學習
要掌握高可用架構，必須先了解主從架構： MySQL-主從架構探索
什么是高可用( HA - High Availability )
通過盡量縮短因日常維護操作（計劃內） 和 突發的系統崩潰 （非計劃）所導致的停機時間，以提高系統的可用性，這就是高可用 。
舉個例子： 主從同步延時太厲害、主從中斷、鎖表造成大量的阻塞 等等因素都造成了應用的不可用，這些都是影響高可用的因素
其實真正做到100%的可用還是比較困難的，我們經常說到的 5個9 （99.999%）的可用 是啥意思呢？
做到 5個9的可用性，那允許停服多長時間呢？ 我們來算下
（365 * 24 * 60） * （1 - 0.99999） = 5.256 分鐘， 一年停服時長小于5分鐘。
4個9呢？
（365 * 24 * 60） * （1 - 0.9999） = 52. 56 分鐘 (1個小時左右)
3個9呢？
（365 * 24 * 60） * （1 - 0.999） = 525.6 分鐘 (9個小時左右)
可用性越高，實現的成本相對就高， 實際情況根據我們的業務和項目成本來考量。
實現高可用的幾點原則
-
避免系統不可用的因素減少系統不可用的時間
比如服務器磁盤空間不足、表結構和索引沒有優化、主從不一致、性能糟糕的SQL、人為操作失誤等等
主要的措施：
建立完善的監控和告警系統
1）備份！！！并對備份數據定期進行恢復測試，以便備份數據在緊急情況恢復數據時可用
2）正確的配置數據庫環境，特別是從庫環境，read_only一定要開啟。
3）對不需要的數據進行歸檔和清理 -
增加系統冗余，確保發生故障時可以盡快的切到另外的節點恢復
主要的措施有：
-
避免存在單點故障
-
主從切換及故障轉移
這里我們主要如何解決探討MySQL的單點故障
避免MySQL單點故障的幾種方案
使用SUN共享存儲
共享存儲 也有單點問題，而且共享存儲的隨機I/O不是很理想，雖然能實現，但不是一種好的解決MySQL單點故障的方案。
使用DRDB磁盤復制
提供遠程鏡像磁盤，數據是由冗余的，沒有單點問題，但成本較高 。
使用用多寫集群（PXC方案）
集群中的節點全部提交才提交。集群的性能取決于集群中機器配置最低的那臺主機的性能。
寫入性能比單節點的寫入性能差， 而且 PXC僅支持Innodb儲存引擎。
這個玩意很強大，需要深入學習，淘寶等很多大廠有基于這個的定制，很好用，但得學會 。
使用NDB集群
這玩意所有的數據存在內存中，如果內存不足，NDB集群的性能就會非常差。 很少在生產環境中使用。
使用MySQL的主從復制
說到使用MySQL主從復制來解決MySQL的單點問題，其核心在于如何解決主節點的單點問題。
要保證主節點高可用，有幾點 需要解決
- 主服務器切換后，如何通知應用新的主服務器的IP地址
- 如何檢查MySQL主服務器是否可用
- 如何處理從服務器和新主服務器之間的那種復制關系
通常都會使用第三方的復制管理組件 ， 主流的MMM 和 MHA ，接下來我們就重點來看下這兩種復制管理組件。
MMM （Multi-Master Replication Manager ）
學習這個之前，需要知道，這個玩意很少有人用了，這個項目好多年都不維護了，了解即可。 有精力可以重點掌握MHA這種架構。
多主復制器， perl語言開發的
MMM的主要作用
監控和管理MySQL的主主復制拓撲，并在當前的主服務器失效的時候，進行主和主備服務器之間的主從切換和故障轉移。
MMM提供的功能
主主復制 分為兩種模式
- 主動-主動模式的主主復制 （兩個主節點都對外提供讀寫服務）
- 主動-被動模式的主主復制（僅一個節點對外提供讀寫服務）
MMM是 主動-被動模式的主主復制的模式
- MMM監控MySQL主從復制的健康狀況
- 在主庫宕機時進行故障轉移并自動配置其他從對新主的復制
這里的內容就比較多了： 比如如何找到從庫對應的新主庫日之巔的日志同步點， 如何存在多個從庫出現數據不一致的情況如何處理 —> MMM采取的方案： 找到當前主庫的同步點進行同步，所以有數據丟失的可能。
- 提供了主、寫虛擬IO，在主從服務器出現問題的時候可以自動遷移虛擬IP
MMM架構圖
因為同一時間點只能有一個主節點提供讀寫服務，所以第二個主節點畫成了虛線。
MMM監控各個服務器的狀態，需要在每臺服務器上安裝 監控服務器。
MMM部署需要的資源
MMM架構安裝和部署
這一部分暫時留空，因為MMM架構使用較少，暫不整理。
MMM架構的優缺點
優點 ：
- 開源，使用perl語言開發
- 提供了讀寫VIP（虛擬IP），使得服務器交涉的變更對前端應用透明。應用訪問DB都是訪問的虛擬IP，而非真實的物理IP。 在從服務器出現大量的主從延遲，主從鏈路中斷時可以把這臺從服務器上的讀的虛擬IP，漂移到集群中其他正常的服務器上。
- MMM提供了從服務器的延遲監控。監控后，有故障可以自動漂移VIP
- MMM提供了主服務器故障轉移后從服務器對新主的重新同步功能
- 很容易對發生故障的主數據庫重新上線
- 監控服務器可以監控多個MMM集群
缺點 ：
- 最新版本10年發布的，十年了。。。。有部分bug未修復
- 不支持MySQL5.6以后的提供的GTID同步方式，僅支持基于binlog的同步
- 不支持MySQL5.6以后的提供的多線程同步技術
- 沒有讀負載的功能
- 主從切換時，容易造成數據丟失
- MMM監控服務存在單點故障，避免的監控服務單點，需要自行實現。
MHA （Master High Availability）
同MMM一樣， 也是perl語言開發
架構
當主節點發生故障時，會在從節點中選舉出一個主節點，繼續提供服務。 切高效的完成主從切換，盡最大可能保證數據一致。
MHA支持 基于GTID的復制 ,GTID復制更安全。
MMM不支持 基于GTID的復制
MHA提供的功能
- 監控主數據庫服務器是否可用
- 當主DB不可用時，從多個從服務器中選舉新的主數據庫服務器
- 提供主從切換和故障轉移功能 。
MHA可以和半同步結合起來使用。
MHA主從切換過程
- 嘗試從出現故障的主數據庫保存二進制日志到其他節點 （需要配置ssh免密）
- 從多個備選從服務器中選舉出新的備選主服務器
- 在備選服務器和其他從服務器之間同步差異的二進制數據
- 應用從原主DB上保存的二進制日志
- 提升備選DB服務器為新的主服務器
- 遷移集群中的其他從DB作為新的DB的從服務器
MHA配置的步驟
- 配置集群內所有的主機的SSH免認證登錄
- 安裝MHA-node軟件包（每個節點都要安裝） 和MHA-manager 軟件包
- 建立主從復制集群 （推薦使用基于GTID的復制）
- 配置MHA管理節點
- 使用masterha_check_ssh和 masterha_check_repl對配置進行校驗
- 啟用并測試MHA服務
MHA的安裝和部署
基于以下架構來演示
篇幅太大，單獨補充
MHA的優缺點
優點
- 開源 ，perl語言開發，提供了腳本接口
- 支持GTID的復制模式
- MHA故障轉移中不容易丟失數據
- 同一個監控節點可以監控多個集群
缺點
- 需要編寫腳本或者利用第三方工具來實現VIP的配置
- MHA啟動后只監控主數據庫
- 需要基于SSH免認證，存在一定的安全隱患
- 也沒有同從服務器的讀的負載功能
搞定MySQL
總結
以上是生活随笔為你收集整理的MySQL-高可用架构探索的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MySQL-binlog格式对主从复制的
- 下一篇： linux cmake编译源码,linu