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

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

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

1. kingbus簡介

1.1 kingbus是什么？

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

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

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

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

1.2 kingbus能解決什么問題？

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

簡化Master Failover流程，只需將連接在kingbus上的一臺Slave提升為Master，并將kingbus重新指向新的Master，其他slave依舊連接在kingbus上，復(fù)制拓撲保持不變。

節(jié)省Master存儲binlog文件的空間。一般MySQL上都是較為昂貴的SSD，如果binlog文件占用空間較多，就使得MySQL存儲的數(shù)據(jù)不得不降低。可以通過將binlog都存儲到kingbus中，從而降低Master上binlog文件的存儲數(shù)量

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

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

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

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

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

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

binlog server，就是一個實現(xiàn)了復(fù)制協(xié)議的Master，真正的slave可以連接到binlog server監(jiān)聽的端口，binlog server會將binlog event發(fā)送給slave，整個發(fā)送binlog event的過程參照MySQL 復(fù)制協(xié)議實現(xiàn)。當沒有binlog event發(fā)送給slave時，binlog server會定期發(fā)送heartbeat event給slave，?；顝?fù)制連接。

api server，負責整個kingbus集群的管理，包括以下內(nèi)容：

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

binlog syncer相關(guān)操作，啟動一個binlog syncer，停止binlog syncer，查看binlog syncer狀態(tài)。

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

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

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

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

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

只有最后一個segment可寫，其文件名為first_raft_index-inprogress，其他segment只讀。

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

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

3.2 etcd raft庫的使用

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

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

binlog syncer主要工作就是：

拉取binlog event

解析并處理binlog event

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

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

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

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

新聞標題：MySQLBinlog存儲系統(tǒng)的架構(gòu)如何設(shè)計
網(wǎng)站地址：http://muchs.cn/article30/igegso.html

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

廣告

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