Mysql 介紹

Mysql是典型的開源關(guān)系型數(shù)據(jù)庫，是許多網(wǎng)站、應(yīng)用程序、企業(yè)軟件產(chǎn)品的首選數(shù)據(jù)庫。

Mysql特性：

• 易于使用，功能強(qiáng)大，支持事務(wù)、觸發(fā)器、存儲過程

• 管理工具多種多樣且功能豐富

• 可以作為千萬級數(shù)據(jù)管理的大型數(shù)據(jù)庫

• 采用GPL開源協(xié)議，允許自由修改源碼并應(yīng)用到商業(yè)系統(tǒng)中

• Mysql的InnoDB事務(wù)性存儲引擎符合事務(wù)ACID模型，能保證完整、可靠地進(jìn)行數(shù)據(jù)地存儲

高可用結(jié)構(gòu)

• 主從模式

• MHA

• MMM

• MGR

主從模式

主從模式介紹

主從模式是最基本的Mysql高可用架構(gòu)，一臺服務(wù)器作為Master節(jié)點(diǎn)，若干服務(wù)器作為Slave節(jié)點(diǎn)。只有Master處理寫數(shù)據(jù)請求，讀請求可僅由Slave節(jié)點(diǎn)處理，也可讓Master、Slave同時(shí)處理。

Master和Slave通過主從復(fù)制技術(shù)保持?jǐn)?shù)據(jù)一致，即Master節(jié)點(diǎn)將數(shù)據(jù)同步給Slave節(jié)點(diǎn)。

主從模式具備高可用的基礎(chǔ)是主從復(fù)制技術(shù)。

主從復(fù)制技術(shù)

• 當(dāng)Master 數(shù)據(jù)發(fā)生變更（新增、刪除、修改）時(shí)，Master將變更日志寫入二進(jìn)制日志文件 binlog

• Slave啟動單獨(dú)線程（I/O線程）與Master建立網(wǎng)絡(luò)連接，從Master的binlog中獲取變更日志

• Slave的I/O線程捕獲到數(shù)據(jù)變更日志后，按照順序保存到中繼日志文件 relay log

• Slave啟動單獨(dú)線程（Sql線程）從relay log 中讀取日志并執(zhí)行，使Slave 庫的數(shù)據(jù)和Master一致

主從模式注意事項(xiàng)

Mysql 5.5之前主從復(fù)制為異步方式，Master 提交事務(wù)不需要經(jīng)過Slave 們的確認(rèn)，那么就會有這種極端情況：

• Slave 讀取Master 的binlog失敗了

• Slave 處理relay log 失敗了

• Slave 執(zhí)行Sql語句失敗了

• 等......

類似的極端情況將導(dǎo)致數(shù)據(jù)不一致。所以在Mysql 5.5 主從復(fù)制提供了半同步的方式，具體來說就是增加了ACK確認(rèn)的機(jī)制，當(dāng)Slave接收到binlog 后，會給Master 發(fā)送一條確認(rèn)消息，Master在接收到ACK確認(rèn)消息之后才會提交事務(wù)。半同步方式可以提高數(shù)據(jù)的一致性，但是Master在寫入數(shù)據(jù)的時(shí)候需要等待Slave的確認(rèn)，所以性能會有所下降。

復(fù)制風(fēng)暴問題，來考慮這樣一種更加極端的情況，一個(gè)Master ，10個(gè)Slave ， 這種情況下基于主從復(fù)制技術(shù)，Master在寫入數(shù)據(jù)前需要同時(shí)處理10個(gè)Slave的數(shù)據(jù)復(fù)制請求，這種情況下對于Master只能說是不堪重負(fù)，如果在加上“半同步機(jī)制”，寫入性能將大打折扣，這種情況稱之為復(fù)制風(fēng)暴問題。解決這種問題的方法是，Master 僅處理一個(gè)Slave的主從復(fù)制，其它的Slave復(fù)制由Slave負(fù)責(zé)。

MHA（MasterHighAvailability）

MHA模式介紹

以主從模式為基礎(chǔ)，接下來就該考慮如下問題了：

• 如何檢測節(jié)點(diǎn)故障

• master節(jié)點(diǎn)故障之后如何重新選舉

MHA就是在解決這兩個(gè)問題的，理論上，MHA模式可以在10s-30s內(nèi)完成主從集群的自動故障檢測和自動主從切換。

MHA由兩個(gè)部分組成：

• MHA-Manager：負(fù)責(zé)自動檢測Master是否故障，檢查主從復(fù)制狀態(tài)，執(zhí)行自動主從切換等。需要單獨(dú)服務(wù)器部署。

• MHA-Node：負(fù)責(zé)修復(fù)主從數(shù)據(jù)的差異，通常和Mysql服務(wù)器實(shí)例綁定部署。

MHA工作流程

• Manager 和 Master之間心跳，如果連續(xù)4次探測不到心跳，就認(rèn)為該Master宕機(jī)了，Master實(shí)例綁定一個(gè)Node。

• Manager 分析各個(gè)Slave的binlog，選擇一個(gè)更接近Master數(shù)據(jù)的Slave作為備選Master，一個(gè)Slave實(shí)例分別綁定一個(gè)Node。

• Slave的Node試圖通過SSH訪問Master所在服務(wù)器：

  如果可達(dá)，Slave的Node獲取Master的binlog數(shù)據(jù)，若發(fā)現(xiàn)Master和Slave數(shù)據(jù)存在差異，會將差異數(shù)據(jù)主動復(fù)制到Slave，以保持主從數(shù)據(jù)一致。

  如果不可達(dá)，Node對比各個(gè)Slave的relay log 差異，并做差異數(shù)據(jù)補(bǔ)齊。

• Manager將備選Master提升為Master。

MMM（Multi-MasterReplicationManagerForMysql）

MMM模式簡單來說就是引入虛擬IP（vip）技術(shù)，這種架構(gòu)下，一個(gè)集群中有兩個(gè)Master和若干個(gè)Slave，當(dāng)其中一個(gè)Master不可用的時(shí)候，MMM會指示vip切換到另外一個(gè)Master上面，同時(shí)會向所有的Slave發(fā)送更換Master的消息，之后主從復(fù)制將切換到新的Master。

此方案比較古老，不支持Mysql GTID ，并且社區(qū)活躍度不夠，目前處于無人維護(hù)的狀態(tài)。

MGR（MysqlGroupReplication）

MGR，Mysql組復(fù)制模式是Mysql5.7.17版本推出的高可用解決方案，具備如下特性：

• 一致性高：數(shù)據(jù)復(fù)制基于分布式共識算法Paxos，可以保證多個(gè)節(jié)點(diǎn)數(shù)據(jù)的一致性

• 容錯(cuò)性高：只要不是超過一半的節(jié)點(diǎn)宕機(jī)，就可以繼續(xù)提供服務(wù)

• 靈活性強(qiáng)：MGR支持單主模式和多主模式，單主模式下如果Master故障，Slave們會重新選舉一個(gè)新的Master，多主模式下每一個(gè)Mysql節(jié)點(diǎn)都可以同時(shí)處理寫請求

MGR要求至少由3個(gè)Mysql節(jié)點(diǎn)組成一個(gè)復(fù)制組，即一主兩從，一個(gè)事務(wù)必須經(jīng)過復(fù)制組內(nèi)超過半數(shù)節(jié)點(diǎn)通過后才能提交。

如果在不同的Mysql節(jié)點(diǎn)上執(zhí)行不同的寫操作發(fā)生了事務(wù)沖突，那么先提交的事務(wù)先執(zhí)行，后提交的事務(wù)被回滾。在多主模式下，由于每個(gè)Mysql節(jié)點(diǎn)都可以執(zhí)行寫請求，在寫請求高并發(fā)的場景下發(fā)生事務(wù)沖突的概率會非常大，會造成大量事務(wù)回滾。

在單主模式下，MGR會自動為復(fù)制組選擇一個(gè)Master負(fù)責(zé)寫請求，如果復(fù)制組內(nèi)超過一半節(jié)點(diǎn)與Master通信失敗，就認(rèn)為Master宕機(jī)了，這時(shí)會根據(jù)各個(gè)節(jié)點(diǎn)的權(quán)重和ID標(biāo)識重新選主。

MGR更加適合一致性強(qiáng)，寫并發(fā)量不大的場景下使用。

總結(jié)

本文闡述了Mysql高可用架構(gòu)方案，介紹了?主從模式，MHA模式，MMM模式，MGR模式?方案的實(shí)現(xiàn)方式，沒有哪個(gè)方案是完美的，開發(fā)人員在選擇何種方案應(yīng)用到項(xiàng)目中也沒有標(biāo)準(zhǔn)答案，合適的才是最好的。

文章轉(zhuǎn)載自：一顆蘋果

原文鏈接：https://www.cnblogs.com/Naylor/p/18539381

體驗(yàn)地址：引邁 - JNPF快速開發(fā)平臺_低代碼開發(fā)平臺_零代碼開發(fā)平臺_流程設(shè)計(jì)器_表單引擎_工作流引擎_軟件架構(gòu)