MySQLBinlog存儲(chǔ)系統(tǒng)的架構(gòu)如何設(shè)計(jì)

這篇文章主要講解了“MySQL Binlog存儲(chǔ)系統(tǒng)的架構(gòu)如何設(shè)計(jì)”,文中的講解內(nèi)容簡(jiǎn)單清晰,易于學(xué)習(xí)與理解,下面請(qǐng)大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“MySQL Binlog存儲(chǔ)系統(tǒng)的架構(gòu)如何設(shè)計(jì)”吧!

創(chuàng)新互聯(lián)建站基于成都重慶香港及美國(guó)等地區(qū)分布式IDC機(jī)房數(shù)據(jù)中心構(gòu)建的電信大帶寬,聯(lián)通大帶寬,移動(dòng)大帶寬,多線BGP大帶寬租用,是為眾多客戶提供專業(yè)四川電信科技城機(jī)房報(bào)價(jià),主機(jī)托管價(jià)格性價(jià)比高,為金融證券行業(yè)服務(wù)器托管,ai人工智能服務(wù)器托管提供bgp線路100M獨(dú)享,G口帶寬及機(jī)柜租用的專業(yè)成都idc公司。

1. kingbus簡(jiǎn)介

1.1 kingbus是什么?

kingbus是一個(gè)基于raft強(qiáng)一致協(xié)議實(shí)現(xiàn)的分布式MySQL binlog 存儲(chǔ)系統(tǒng)。它能夠充當(dāng)一個(gè)MySQL Slave從真正的Master上同步binlog,并存儲(chǔ)在分布式集群中。同時(shí)又充當(dāng)一個(gè)MySQL Master將集群中的binlog 同步給其他Slave。 kingbus具有如下特性:

兼容MySQL 復(fù)制協(xié)議,通過Gtid方式同步Master上的binlog,同時(shí)支持slave通過Gtid方式從kingbus拉取binlog。

跨地域數(shù)據(jù)復(fù)制,kingbus通過raft協(xié)議支持跨地域間的數(shù)據(jù)復(fù)制。寫入到集群的binlog數(shù)據(jù)在多個(gè)節(jié)點(diǎn)間保證強(qiáng)一致,并保證binlog順序與master上完全一致。

高可用,由于kingbus是構(gòu)建在Raft強(qiáng)一致協(xié)議之上,能夠?qū)崿F(xiàn)集群中過半數(shù)節(jié)點(diǎn)存活的情況下,整個(gè)binlog拉取和推送服務(wù)高可用。

1.2 kingbus能解決什么問題?

kingbus能降低Master的網(wǎng)絡(luò)傳輸流量。在一主多從的復(fù)制拓?fù)渲?,Master需要發(fā)送binlog到各個(gè)slave,如果slave過多的話,網(wǎng)絡(luò)流量很有可能達(dá)到Master的網(wǎng)卡上限。例如在Master執(zhí)行delete大表或者online DDL等操作,都有可能造成瞬間生成大量的binlog event,如果master下面掛10臺(tái)slave的話,master上的網(wǎng)卡流量就會(huì)放大10倍。如果master使用千兆網(wǎng)卡,產(chǎn)生了10MB/S以上的流量就有可能將其網(wǎng)卡跑滿。通過kingbus連接master的方式,可以將slave分散到多臺(tái)機(jī)器上,從而均衡傳輸流量。

簡(jiǎn)化Master Failover流程,只需將連接在kingbus上的一臺(tái)Slave提升為Master,并將kingbus重新指向新的Master,其他slave依舊連接在kingbus上,復(fù)制拓?fù)浔3植蛔儭?/p>

節(jié)省Master存儲(chǔ)binlog文件的空間。一般MySQL上都是較為昂貴的SSD,如果binlog文件占用空間較多,就使得MySQL存儲(chǔ)的數(shù)據(jù)不得不降低??梢酝ㄟ^將binlog都存儲(chǔ)到kingbus中,從而降低Master上binlog文件的存儲(chǔ)數(shù)量

支持異構(gòu)復(fù)制。通過阿里巴巴開源的canal連接到kingbus,kingbus源源不斷推送binlog給canal,canal接收完binlog再推送給kafka消息隊(duì)列,最終存入HBase里,業(yè)務(wù)部門通過Hive直接寫SQL的方式來實(shí)現(xiàn)業(yè)務(wù)的實(shí)時(shí)分析。

2.kingbus總體架構(gòu)

kingbus整體架構(gòu)如下圖所示:

storage負(fù)責(zé)存儲(chǔ)raft log entry和Metadata,在kingbus中,將raft log和mysql binlog融合在一起了,通過不同的頭部信息區(qū)分,raft log的數(shù)據(jù)部分就是binlog event,這樣就不需要分開存儲(chǔ)兩類log,節(jié)省存儲(chǔ)空間。因?yàn)閗ingbus需要存儲(chǔ)一些元信息,例如raft 節(jié)點(diǎn)投票信息、某些特殊binlog event的具體內(nèi)容(FORMAT_DESCRIPTION_EVENT)。

raft復(fù)制kingbus集群的Lead選舉、日志復(fù)制等功能,使用的是etcd raft library。

binlog syncer,只運(yùn)行在Raft集群的Lead節(jié)點(diǎn)上,整個(gè)集群只有一個(gè)syncer。syncer偽裝成一個(gè)slave,向Master建立主從復(fù)制連接,Master會(huì)根據(jù)syncer發(fā)送的executed_gtid_set過濾syncer已經(jīng)接受的binlog event,只發(fā)送syncer沒有接收過的binlog event,這套復(fù)制協(xié)議完全兼容MySQL 主從復(fù)制機(jī)制。syncer收到binlog event后,會(huì)根據(jù)binlog event類型做一些處理,然后將binlog event封裝成一個(gè)消息提交到raft 集群中。通過raft算法,這個(gè)binlog event就可以在多個(gè)節(jié)點(diǎn)存儲(chǔ),并達(dá)到強(qiáng)一致的效果。

binlog server,就是一個(gè)實(shí)現(xiàn)了復(fù)制協(xié)議的Master,真正的slave可以連接到binlog server監(jiān)聽的端口,binlog server會(huì)將binlog event發(fā)送給slave,整個(gè)發(fā)送binlog event的過程參照MySQL 復(fù)制協(xié)議實(shí)現(xiàn)。當(dāng)沒有binlog event發(fā)送給slave時(shí),binlog server會(huì)定期發(fā)送heartbeat event給slave,保活復(fù)制連接。

api server,負(fù)責(zé)整個(gè)kingbus集群的管理,包括以下內(nèi)容:

raft cluster membership操作,查看集群狀態(tài),添加一個(gè)節(jié)點(diǎn)、移除一個(gè)節(jié)點(diǎn),更新節(jié)點(diǎn)信息等

binlog syncer相關(guān)操作,啟動(dòng)一個(gè)binlog syncer,停止binlog syncer,查看binlog syncer狀態(tài)。

binlog server相關(guān)操作,啟動(dòng)一個(gè)binlog server,停止binlog server,查看binlog server狀態(tài)。 server層的各種異常,都不會(huì)影響到raft層,server可以理解為一種插件,按需啟動(dòng)和停止。以后擴(kuò)展kingbus時(shí),只需要實(shí)現(xiàn)相關(guān)邏輯的server就行。例如實(shí)現(xiàn)一個(gè)kafka協(xié)議的server,那么就可以通過kafka client消費(fèi)kingbus中的消息。

3.kingbus核心實(shí)現(xiàn)

3.1 storage的核心實(shí)現(xiàn)

storage中有兩種日志形態(tài),一種是raft日志(以下稱為raft log),由raft算法產(chǎn)生和使用,另一種是用戶形態(tài)的Log(也就是mysql binlog event)。Storage在設(shè)計(jì)中,將兩種Log形態(tài)組合成一個(gè)Log Entry。只是通過不同的頭部信息來區(qū)分。Storage由數(shù)據(jù)文件和索引文件組成,如下圖所示:

segment固定大?。?GB),只能追加寫入,名字為first_raft_index-last_raft_index,表示該segment的raft index范圍。

只有最后一個(gè)segment可寫,其文件名為first_raft_index-inprogress,其他segment只讀。

只讀的segment和對(duì)應(yīng)的index file都是通過mmap方式寫入和讀取。

最后一個(gè)segment的index 內(nèi)容同時(shí)存儲(chǔ)在磁盤和內(nèi)存。讀取索引是只需要在內(nèi)存中讀取。

3.2 etcd raft庫(kù)的使用

Etcd raft library在處理已經(jīng)Apply的日志、committed entries等內(nèi)容時(shí),是單線程處理的。具體函數(shù)參考鏈接,這個(gè)函數(shù)處理時(shí)間要確保盡可能短,如果處理時(shí)間超過raft 選舉時(shí)間,會(huì)造成集群重新選舉。這一點(diǎn)需要特別注意。

3.3 binlog syncer的核心實(shí)現(xiàn)

binlog syncer主要工作就是:

拉取binlog event

解析并處理binlog event

提交binlog event到raft 集群。 很明顯可以通過pipeline機(jī)制來提個(gè)整個(gè)過程的處理速度,每個(gè)階段kingbus都使用單獨(dú)的goroutine來處理,通過管道來銜接不同階段。 由于binlog syncer是按照binlog event一個(gè)一個(gè)接收的,syncer并不能保證事務(wù)完整性,有可能在syncer掛了后,需要重新連接Master,這時(shí)候最后一個(gè)事務(wù)有可能不完整,binlog syncer需要有發(fā)現(xiàn)事務(wù)完整性的能力,kingbus實(shí)現(xiàn)了事務(wù)完整性解析的功能,完全參考MySQL源碼實(shí)現(xiàn)。

3.4 binlog server的核心實(shí)現(xiàn)

binlog server實(shí)現(xiàn)了一個(gè)master的功能,slave與binlog server建立復(fù)制連接時(shí),slave會(huì)發(fā)送相關(guān)命令,binlog server需要響應(yīng)這些命令。最終發(fā)送binlog event給slave。對(duì)于每個(gè)slave,binlog server會(huì)啟動(dòng)一個(gè)goroutine不斷讀取raft log,并去掉相關(guān)頭部信息,就變成了binlog event,然后再發(fā)送給slave。

感謝各位的閱讀,以上就是“MySQL Binlog存儲(chǔ)系統(tǒng)的架構(gòu)如何設(shè)計(jì)”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對(duì)MySQL Binlog存儲(chǔ)系統(tǒng)的架構(gòu)如何設(shè)計(jì)這一問題有了更深刻的體會(huì),具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián),小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章,歡迎關(guān)注!

新聞標(biāo)題:MySQLBinlog存儲(chǔ)系統(tǒng)的架構(gòu)如何設(shè)計(jì)
網(wǎng)站地址:http://bm7419.com/article30/igegso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供電子商務(wù)、移動(dòng)網(wǎng)站建設(shè)、建站公司、App設(shè)計(jì)、軟件開發(fā)服務(wù)器托管

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都做網(wǎng)站