當(dāng)前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

MySQL-高可用架构探索

發(fā)布時間：2025/3/21 数据库 25 豆豆

生活随笔收集整理的這篇文章主要介紹了 MySQL-高可用架构探索小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

文章目錄

生猛干貨
官方文檔
前置學(xué)習(xí)
什么是高可用( HA - High Availability )
實現(xiàn)高可用的幾點原則
避免MySQL單點故障的幾種方案
- 使用SUN共享存儲
- 使用DRDB磁盤復(fù)制
- 使用用多寫集群（PXC方案）
- 使用NDB集群
- 使用MySQL的主從復(fù)制
MMM （Multi-Master Replication Manager ）
- MMM的主要作用
- MMM提供的功能
- MMM架構(gòu)圖
- MMM部署需要的資源
- MMM架構(gòu)安裝和部署
- MMM架構(gòu)的優(yōu)缺點
MHA （Master High Availability）
- 架構(gòu)
- MHA提供的功能
- MHA主從切換過程
- MHA配置的步驟
- MHA的安裝和部署
- MHA的優(yōu)缺點
搞定MySQL

生猛干貨

帶你搞定MySQL實戰(zhàn)，輕松對應(yīng)海量業(yè)務(wù)處理及高并發(fā)需求，從容應(yīng)對大場面試

官方文檔

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

前置學(xué)習(xí)

要掌握高可用架構(gòu)，必須先了解主從架構(gòu)： MySQL-主從架構(gòu)探索

什么是高可用( HA - High Availability )

通過盡量縮短因日常維護操作（計劃內(nèi)）和突發(fā)的系統(tǒng)崩潰（非計劃）所導(dǎo)致的停機時間，以提高系統(tǒng)的可用性，這就是高可用。

舉個例子：主從同步延時太厲害、主從中斷、鎖表造成大量的阻塞等等因素都造成了應(yīng)用的不可用，這些都是影響高可用的因素

其實真正做到100%的可用還是比較困難的，我們經(jīng)常說到的 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個小時左右)

可用性越高，實現(xiàn)的成本相對就高，實際情況根據(jù)我們的業(yè)務(wù)和項目成本來考量。

實現(xiàn)高可用的幾點原則

避免系統(tǒng)不可用的因素減少系統(tǒng)不可用的時間

比如服務(wù)器磁盤空間不足、表結(jié)構(gòu)和索引沒有優(yōu)化、主從不一致、性能糟糕的SQL、人為操作失誤等等

主要的措施：

建立完善的監(jiān)控和告警系統(tǒng)

1）備份！！！并對備份數(shù)據(jù)定期進行恢復(fù)測試，以便備份數(shù)據(jù)在緊急情況恢復(fù)數(shù)據(jù)時可用
2）正確的配置數(shù)據(jù)庫環(huán)境，特別是從庫環(huán)境，read_only一定要開啟。
3）對不需要的數(shù)據(jù)進行歸檔和清理
增加系統(tǒng)冗余，確保發(fā)生故障時可以盡快的切到另外的節(jié)點恢復(fù)

主要的措施有：
避免存在單點故障
主從切換及故障轉(zhuǎn)移

這里我們主要如何解決探討MySQL的單點故障

避免MySQL單點故障的幾種方案

使用SUN共享存儲

共享存儲也有單點問題，而且共享存儲的隨機I/O不是很理想，雖然能實現(xiàn)，但不是一種好的解決MySQL單點故障的方案。

使用DRDB磁盤復(fù)制

提供遠程鏡像磁盤，數(shù)據(jù)是由冗余的，沒有單點問題，但成本較高。

使用用多寫集群（PXC方案）

集群中的節(jié)點全部提交才提交。集群的性能取決于集群中機器配置最低的那臺主機的性能。

寫入性能比單節(jié)點的寫入性能差，而且 PXC僅支持Innodb儲存引擎。

這個玩意很強大，需要深入學(xué)習(xí)，淘寶等很多大廠有基于這個的定制，很好用，但得學(xué)會。

使用NDB集群

這玩意所有的數(shù)據(jù)存在內(nèi)存中，如果內(nèi)存不足，NDB集群的性能就會非常差。很少在生產(chǎn)環(huán)境中使用。

使用MySQL的主從復(fù)制

說到使用MySQL主從復(fù)制來解決MySQL的單點問題，其核心在于如何解決主節(jié)點的單點問題。

要保證主節(jié)點高可用，有幾點需要解決

主服務(wù)器切換后，如何通知應(yīng)用新的主服務(wù)器的IP地址
如何檢查MySQL主服務(wù)器是否可用
如何處理從服務(wù)器和新主服務(wù)器之間的那種復(fù)制關(guān)系

通常都會使用第三方的復(fù)制管理組件，主流的MMM 和 MHA ，接下來我們就重點來看下這兩種復(fù)制管理組件。

MMM （Multi-Master Replication Manager ）

學(xué)習(xí)這個之前，需要知道，這個玩意很少有人用了，這個項目好多年都不維護了，了解即可。有精力可以重點掌握MHA這種架構(gòu)。

多主復(fù)制器， perl語言開發(fā)的

MMM的主要作用

監(jiān)控和管理MySQL的主主復(fù)制拓撲，并在當(dāng)前的主服務(wù)器失效的時候，進行主和主備服務(wù)器之間的主從切換和故障轉(zhuǎn)移。

MMM提供的功能

主主復(fù)制分為兩種模式

主動-主動模式的主主復(fù)制（兩個主節(jié)點都對外提供讀寫服務(wù)）
主動-被動模式的主主復(fù)制（僅一個節(jié)點對外提供讀寫服務(wù)）

MMM是主動-被動模式的主主復(fù)制的模式

MMM監(jiān)控MySQL主從復(fù)制的健康狀況
在主庫宕機時進行故障轉(zhuǎn)移并自動配置其他從對新主的復(fù)制

這里的內(nèi)容就比較多了：比如如何找到從庫對應(yīng)的新主庫日之巔的日志同步點，如何存在多個從庫出現(xiàn)數(shù)據(jù)不一致的情況如何處理 —> MMM采取的方案：找到當(dāng)前主庫的同步點進行同步，所以有數(shù)據(jù)丟失的可能。

提供了主、寫虛擬IO，在主從服務(wù)器出現(xiàn)問題的時候可以自動遷移虛擬IP

MMM架構(gòu)圖

因為同一時間點只能有一個主節(jié)點提供讀寫服務(wù)，所以第二個主節(jié)點畫成了虛線。

MMM監(jiān)控各個服務(wù)器的狀態(tài)，需要在每臺服務(wù)器上安裝監(jiān)控服務(wù)器。

MMM部署需要的資源

MMM架構(gòu)安裝和部署

這一部分暫時留空，因為MMM架構(gòu)使用較少，暫不整理。

MMM架構(gòu)的優(yōu)缺點

優(yōu)點：

開源，使用perl語言開發(fā)
提供了讀寫VIP（虛擬IP），使得服務(wù)器交涉的變更對前端應(yīng)用透明。應(yīng)用訪問DB都是訪問的虛擬IP，而非真實的物理IP。在從服務(wù)器出現(xiàn)大量的主從延遲，主從鏈路中斷時可以把這臺從服務(wù)器上的讀的虛擬IP，漂移到集群中其他正常的服務(wù)器上。
MMM提供了從服務(wù)器的延遲監(jiān)控。監(jiān)控后，有故障可以自動漂移VIP
MMM提供了主服務(wù)器故障轉(zhuǎn)移后從服務(wù)器對新主的重新同步功能
很容易對發(fā)生故障的主數(shù)據(jù)庫重新上線
監(jiān)控服務(wù)器可以監(jiān)控多個MMM集群

缺點：

最新版本10年發(fā)布的，十年了。。。。有部分bug未修復(fù)
不支持MySQL5.6以后的提供的GTID同步方式，僅支持基于binlog的同步
不支持MySQL5.6以后的提供的多線程同步技術(shù)
沒有讀負載的功能
主從切換時，容易造成數(shù)據(jù)丟失
MMM監(jiān)控服務(wù)存在單點故障，避免的監(jiān)控服務(wù)單點，需要自行實現(xiàn)。

MHA （Master High Availability）

同MMM一樣，也是perl語言開發(fā)

架構(gòu)

當(dāng)主節(jié)點發(fā)生故障時，會在從節(jié)點中選舉出一個主節(jié)點，繼續(xù)提供服務(wù)。切高效的完成主從切換，盡最大可能保證數(shù)據(jù)一致。

MHA支持基于GTID的復(fù)制 ,GTID復(fù)制更安全。
MMM不支持基于GTID的復(fù)制

MHA提供的功能

監(jiān)控主數(shù)據(jù)庫服務(wù)器是否可用
當(dāng)主DB不可用時，從多個從服務(wù)器中選舉新的主數(shù)據(jù)庫服務(wù)器
提供主從切換和故障轉(zhuǎn)移功能。

MHA可以和半同步結(jié)合起來使用。

MHA主從切換過程

嘗試從出現(xiàn)故障的主數(shù)據(jù)庫保存二進制日志到其他節(jié)點（需要配置ssh免密）
從多個備選從服務(wù)器中選舉出新的備選主服務(wù)器
在備選服務(wù)器和其他從服務(wù)器之間同步差異的二進制數(shù)據(jù)
應(yīng)用從原主DB上保存的二進制日志
提升備選DB服務(wù)器為新的主服務(wù)器
遷移集群中的其他從DB作為新的DB的從服務(wù)器

MHA配置的步驟

配置集群內(nèi)所有的主機的SSH免認證登錄
安裝MHA-node軟件包（每個節(jié)點都要安裝）和MHA-manager 軟件包
建立主從復(fù)制集群（推薦使用基于GTID的復(fù)制）
配置MHA管理節(jié)點
使用masterha_check_ssh和 masterha_check_repl對配置進行校驗
啟用并測試MHA服務(wù)

MHA的安裝和部署

基于以下架構(gòu)來演示

篇幅太大，單獨補充

MHA的優(yōu)缺點

優(yōu)點

開源，perl語言開發(fā)，提供了腳本接口
支持GTID的復(fù)制模式
MHA故障轉(zhuǎn)移中不容易丟失數(shù)據(jù)
同一個監(jiān)控節(jié)點可以監(jiān)控多個集群

缺點

需要編寫腳本或者利用第三方工具來實現(xiàn)VIP的配置
MHA啟動后只監(jiān)控主數(shù)據(jù)庫
需要基于SSH免認證，存在一定的安全隱患
也沒有同從服務(wù)器的讀的負載功能

搞定MySQL

總結(jié)

以上是生活随笔為你收集整理的MySQL-高可用架构探索的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

MySQL
架构

上一篇： MySQL-binlog格式对主从复制的
下一篇： MySQL-通过MaxScale实现读写