您好,登錄后才能下訂單哦!
并發(fā)復(fù)制(Parallel Replication) 系列二: Enhanced Multi-threaded Slaves
作者:沃趣科技MySQL數(shù)據(jù)庫工程師 麻鵬飛
首先梳理下傳統(tǒng)MySQL/MariaDB主備復(fù)制基本原理:
主從復(fù)制通過三個(gè)線程來完成,在master節(jié)點(diǎn)運(yùn)行的binlog dump的線程,I/O線程和SQL線程運(yùn)行在slave 節(jié)點(diǎn)
master節(jié)點(diǎn)的Binlog dump線程,當(dāng)slave節(jié)點(diǎn)與master正常連接的時(shí)候,master把更新的binlog 內(nèi)容推送到slave節(jié)點(diǎn)。
slave節(jié)點(diǎn)的I/O 線程 ,該線程通過讀取master節(jié)點(diǎn)binlog日志名稱以及偏移量信息將其拷貝到本地relay log日志文件。
slave節(jié)點(diǎn)的SQL線程,該線程讀取relay log日志信息,將在master節(jié)點(diǎn)上提交的事務(wù)在本地回放,達(dá)到與主庫數(shù)據(jù)保持一致的目的。
問題1:
Master節(jié)點(diǎn)的數(shù)據(jù)庫實(shí)例并發(fā)跑多個(gè)線程同時(shí)提交事務(wù),提交的事務(wù)按照邏輯的時(shí)間(數(shù)據(jù)庫LSN號(hào))順序地寫入binary log日志,,slave節(jié)點(diǎn)通過I/O線程寫到本地的relay log日志,但是slave節(jié)點(diǎn)只有SQL單線程來執(zhí)行relay log中的日志信息重放主庫提交得事務(wù),造成主備數(shù)據(jù)庫存在延遲(lag)
思考1:
那么為了減少主備數(shù)據(jù)同步延遲時(shí)間,由于備庫只有單線程補(bǔ)償數(shù)據(jù)的原因而造成延遲,那么能否使slave節(jié)點(diǎn)同時(shí)運(yùn)行多個(gè)如SQL線程一樣的功能來重放在主庫執(zhí)行的事務(wù)?答案當(dāng)然是:可以!但是我們需要解決以下問題:
1、slave本地的relay log記錄的是master 的binary log日志信息,日志記錄的信息按照事務(wù)的時(shí)間先后順序記錄,那么為了保證主備數(shù)據(jù)一致性,slave節(jié)點(diǎn)必須按照同樣的順序執(zhí)行,如果順序不一致容易造成主備庫數(shù)據(jù)不一致的風(fēng)險(xiǎn)。
如:
在master節(jié)點(diǎn)提交T1和T2事務(wù)按照以下順序
slave節(jié)點(diǎn)執(zhí)行T1和T2相反的順序:
MySQL 5.6改進(jìn):
MySQL 5.6版本引入并發(fā)復(fù)制(schema級(jí)別),基于schema級(jí)別的并發(fā)復(fù)制核心思想:“不同schema下的表并發(fā)提交時(shí)的數(shù)據(jù)不會(huì)相互影響,即slave節(jié)點(diǎn)可以用對(duì)relay log中不同的schema各分配一個(gè)類似SQL功能的線程,來重放relay log中主庫已經(jīng)提交的事務(wù),保持?jǐn)?shù)據(jù)與主庫一致”??梢奙ySQL5.6版本的并發(fā)復(fù)制,一個(gè)schema分配一個(gè)類似SQL線程的功能。
實(shí)現(xiàn)1:
slave節(jié)點(diǎn)開啟并發(fā)復(fù)制(slave_parallel_workers=3)如下圖,當(dāng)前的slave的SQL線程為Coordinator(協(xié)調(diào)器),執(zhí)行relay log日志的線程為worker(當(dāng)前的SQL線程不僅起到協(xié)調(diào)器的作用,同時(shí)也可以重放relay log中主庫提交的事務(wù))
問題2:
MySQL 5.6基于schema級(jí)別的并發(fā)復(fù)制能夠解決當(dāng)業(yè)務(wù)數(shù)據(jù)的表放在不同的database庫下,但是實(shí)際生產(chǎn)中往往大多數(shù)或者全部的業(yè)務(wù)數(shù)據(jù)表都放在同一個(gè)schema下,在這種場(chǎng)景即使slave_parallel_workers>0設(shè)置也無法并發(fā)執(zhí)行relay log中記錄的主庫提交數(shù)據(jù)。 高并發(fā)的情況下,由于slave無法并發(fā)執(zhí)行同個(gè)schema下的業(yè)務(wù)數(shù)據(jù)表,依然會(huì)造成主備延遲的情況。
思考2:
那么如果slave同時(shí)可以用多線程的方式,同時(shí)執(zhí)行一個(gè)schema下的所有業(yè)務(wù)數(shù)據(jù)表,將能大大提高slave節(jié)點(diǎn)執(zhí)行ralay log中記錄的主庫提交事務(wù)達(dá)到與主庫數(shù)據(jù)同步的目的,實(shí)現(xiàn)該功能我們需要解決什么問題?
1、前面提到過為了保證主庫數(shù)據(jù)一致性,master節(jié)點(diǎn)寫入的binary log日志按照數(shù)據(jù)庫邏輯時(shí)間先后的順序并且slave節(jié)點(diǎn)執(zhí)行relay log中主庫提交的事務(wù)必須按照一致的順序否則會(huì)造成主備數(shù)據(jù)不一致的情況。
2、既然要實(shí)現(xiàn)scehma下所有的業(yè)務(wù)數(shù)據(jù)表能夠并發(fā)執(zhí)行,那么slave必須得知道并發(fā)執(zhí)行relay log中主庫提交的事務(wù)不能相互影響而且結(jié)果必須和主庫保持一致。
實(shí)現(xiàn)2:
MySQL 5.7 引入Enhanced Muti-threaded slaves,當(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ù)。但是要實(shí)現(xiàn)以上功能,需要在master機(jī)器標(biāo)記binary log中的提交的事務(wù)哪些是可以并發(fā)執(zhí)行,雖然MySQL 5.6已經(jīng)引入了binary log group commit,但是沒有將可以并發(fā)執(zhí)行的事務(wù)標(biāo)記出來。
我們用命令 mysqlbinlog -vvv mysqlbinlog.0000003 | grep -i last_committed 在MySQL 5.7的master機(jī)器上可以看到last_committed 和sequence_number
slave機(jī)器的relay log中 last_committed相同的事務(wù)(sequence_num不同)可以并發(fā)執(zhí)行。從上面截取的信息可以看出last_committed=26的事務(wù)一共有8個(gè):從sequence_number=27~24。假設(shè)當(dāng)slave_parallel_workers=7時(shí),Coordinator線程(SQL線程)分配這一組事務(wù)到worker中排隊(duì)去執(zhí)行。這里可以看出增加master庫binary log group commit組中事務(wù)的數(shù)量可以提高slave機(jī)器并發(fā)處理事務(wù)的數(shù)量,MySQL5.7引入 binlog_group_commit_sync_delay和 binlog_group_commit_sync_no_delay_count參數(shù)即提高binary log組提交并發(fā)數(shù)量。MySQL等待binlog_group_commit_sync_delay毫秒的時(shí)間直到binlog_group_commit_sync_no_delay_count個(gè)事務(wù)數(shù)時(shí),將進(jìn)行一次組提交。
總結(jié):
MySQL 5.7 GA版本推出的 Enhanced Multi-threaded Slaves功能,徹底解決了之前版本主備數(shù)據(jù)復(fù)制延遲的問題,開啟該功能參數(shù)如下:
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。