MySQL之高可用架構(gòu)的示例分析

小編給大家分享一下MySQL之高可用架構(gòu)的示例分析，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

MySQL高可用

MySQL的高可用也是同樣的思路，首先要有多個(gè)MySQL實(shí)例提供服務(wù)，其次就是當(dāng)某個(gè)實(shí)例掛掉時(shí)，可以自動(dòng)切換流量。同時(shí)MySQL作為存儲(chǔ)，節(jié)點(diǎn)之間數(shù)據(jù)同步也是一個(gè)難題（換句話說，有狀態(tài)的服務(wù)都面臨這個(gè)問題）。

一主一備：

MySQL的各種高可用架構(gòu)，都脫離不了MySQL實(shí)例之間的數(shù)據(jù)同步，因此，我們先介紹下最簡單的一主一備架構(gòu)下MySQL的數(shù)據(jù)同步流程。

上圖是主從數(shù)據(jù)同步的一個(gè)示意圖。

Master節(jié)點(diǎn)有Dump進(jìn)程把binlog中的數(shù)據(jù)發(fā)送到Slave節(jié)點(diǎn)，

Slave節(jié)點(diǎn)有IO進(jìn)程接收數(shù)據(jù)寫入relay log，

Slave節(jié)點(diǎn)的SQL進(jìn)程根據(jù)relay log寫入數(shù)據(jù)。

這里還要延伸一點(diǎn)，binlog存在三種形式：Statement、Row、Mixed。

Statement：就是把每一條SQL記錄到binlog中。

Row：是把每一行修改的具體數(shù)據(jù)記錄到binlog中。

Mixed：MySQL會(huì)靈活的區(qū)分，需要記錄sql還是具體修改的記錄。

只記錄SQL的話binlog會(huì)比較小，但是有些SQL語句在主從同步數(shù)據(jù)的時(shí)候，可能會(huì)因?yàn)檫x擇不同的索引在數(shù)據(jù)同步過程中出現(xiàn)數(shù)據(jù)不一致。記錄Row的話就可以保證主從同步不會(huì)存在SQL語意偏差的問題，同時(shí)Row類型的日志在做數(shù)據(jù)恢復(fù)的時(shí)候也比較容易，但是Row會(huì)導(dǎo)致binlog過大。

MySQL主從同步的幾種模式：

異步模式：
在這種同步策略下，主庫按照自己的流程處理完數(shù)據(jù)，會(huì)直接返回結(jié)果，不會(huì)等待主庫和從庫之間的數(shù)據(jù)同步。 優(yōu)點(diǎn)：效率高。 缺點(diǎn)：Master節(jié)點(diǎn)掛掉之后，Slave節(jié)點(diǎn)會(huì)丟失數(shù)據(jù)。全同步模式： 主庫會(huì)等待所有從庫都執(zhí)行完sql語句并ACK完成，才返回成功。 優(yōu)點(diǎn)：有很好的數(shù)據(jù)一致性保障。 缺點(diǎn)：會(huì)造成數(shù)據(jù)操作延遲，降低了MySQL的吞吐量。半同步模式：主庫會(huì)等待至少有一個(gè)從庫把數(shù)據(jù)寫入relay log并ACK完成，才成功返回結(jié)果。 半同步模式介于異步和全同步之間。

半同步的復(fù)制方案是在MySQL5.5開始引入的，普通的半同步復(fù)制方案步驟如下圖：

Master節(jié)點(diǎn)寫數(shù)據(jù)到Binlog，并且執(zhí)行Sync操作。Master發(fā)送數(shù)據(jù)給Slave節(jié)點(diǎn)，同時(shí)commit主庫的事務(wù)。收到ACK后Master節(jié)點(diǎn)把數(shù)據(jù)返回給客戶端。

這種數(shù)據(jù)提交模式叫： after_commit

after_commit 模式存在問題： 主庫等待ACK時(shí)，事務(wù)已經(jīng)commit，主庫的其他事務(wù)可以讀到commit的數(shù)據(jù)，這個(gè)時(shí)候如果Master崩潰，slave數(shù)據(jù)丟失，發(fā)生主從切換，會(huì)導(dǎo)致出現(xiàn)幻讀。 為了解決這個(gè)問題MySQL5.7提出了新的半同步復(fù)制模式： after_sync

把主庫的事務(wù)提交放到了ACK之后，避免了上述問題。 MySQL5.7還引入了 enhanced multi-threaded slave （簡稱MTS）模式, 當(dāng)slave配置 slave_parallel_workers >0并且
global.slave_parallel_type ＝‘LOGICAL_CLOCK',可支持一個(gè)schema下，slave_parallel_workers個(gè)worker線程并發(fā)執(zhí)行relay log中主庫提交的事務(wù)，極大地提高了主從復(fù)制的效率。 MySQL5.7半同步功能可以通過
rpl_semi_sync_master_wait_slave_count 參數(shù)配置slave節(jié)點(diǎn)ACK的個(gè)數(shù)，認(rèn)為主從同步完成。

基于MySQL主從同步數(shù)據(jù)越來越完善，效率越來越高，也就引出了第一種MySQL的高可用架構(gòu)： 基于MySQL自身的主從同步方案，常用的一種部署架構(gòu)是： 用戶通過VIP訪問Master和Slave節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)采用keepalved探索。配置主從關(guān)系，進(jìn)行數(shù)據(jù)同步。

基于MHA的高可用架構(gòu)： 部署一份MHA的Manager節(jié)點(diǎn)，在MySQL各個(gè)實(shí)例部署MHA Node節(jié)點(diǎn)。MHA可以實(shí)現(xiàn)秒級(jí)的故障自動(dòng)轉(zhuǎn)移。 當(dāng)然MySQL節(jié)點(diǎn)之間的數(shù)據(jù)同步還要依賴MySQL自身的數(shù)據(jù)同步方式。

MGR(MySQL Group Replication)模式： 感覺MySQL官方更看好MGR集群方案，但是目前我還不知道國內(nèi)有哪一家公司在使用。 MGR集群是由所有的MySQL Server共同組成的，每個(gè)Server都有完整的副本數(shù)據(jù)，副本之間基于Row格式的日志和GTID來做副本之前的數(shù)據(jù)同步，采用Paxos算法實(shí)現(xiàn)數(shù)據(jù)的一致性保障。 MGR架構(gòu)要比前面講述的半同步和異步同步數(shù)據(jù)的方式要復(fù)雜，具體可以參照 官網(wǎng)

看完了這篇文章，相信你對(duì)“MySQL之高可用架構(gòu)的示例分析”有了一定的了解，如果想了解更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！