淺析MySQL并行復(fù)制
01 并行復(fù)制的概念
在MySQL的主從復(fù)制架構(gòu)中,主庫(kù)上經(jīng)常會(huì)并發(fā)的執(zhí)行很多SQL,只要這些SQL沒有產(chǎn)生鎖等待,那么同一時(shí)間并發(fā)好幾個(gè)SQL線程是沒有問題的。
我們知道,MySQL的從庫(kù)是要通過IO_thread去拉取主庫(kù)上的binlog的,然后存入本地,落盤成relay-log,通過sql_thread來應(yīng)用這些relay-log。
在MySQL5.6之前的版本中,當(dāng)主庫(kù)上有多個(gè)線程并發(fā)執(zhí)行SQL時(shí),sql_thread只有一個(gè),在某些TPS比較高的場(chǎng)景下,會(huì)出現(xiàn)主庫(kù)嚴(yán)重延遲的問題。MySQL為了解決這個(gè)問題,將sql_thread演化了多個(gè)worker的形式,在slave端并行應(yīng)用relay log中的事務(wù),從而提高relay log的應(yīng)用速度,減少?gòu)?fù)制延遲。這就是并行復(fù)制的由來。
在MySQL中,復(fù)制線程是由參數(shù)slave_parallel_workers來控制的,通常情況下,在8G內(nèi)存、8核CPU的機(jī)器上,將該值設(shè)置為8比較合適,如果你的CPU核數(shù)比較高,那么可以適當(dāng)調(diào)整為8~16之間的數(shù)字。
mysql> show variables like 'slave_parallel_workers'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | slave_parallel_workers | 8 | +------------------------+-------+ 1 row in set, 1 warning (0.00 sec)
02 并行復(fù)制的演進(jìn)
并行復(fù)制的本質(zhì)是同時(shí)執(zhí)行的SQL不存在鎖爭(zhēng)用。
在MySQL5.6版本,MySQL支持的粒度是按照數(shù)據(jù)庫(kù)進(jìn)行并行執(zhí)行relay log,這種方式能夠解決一部分問題,因?yàn)椴煌瑪?shù)據(jù)庫(kù)上的SQL,肯定不會(huì)修改表中的同一行內(nèi)容。這樣也就不會(huì)產(chǎn)生鎖爭(zhēng)用。在一些數(shù)據(jù)庫(kù)均勻分布,每個(gè)數(shù)據(jù)庫(kù)使用頻率都差不多的場(chǎng)景下,這種并行復(fù)制的方法比較好。如果你的業(yè)務(wù)的數(shù)據(jù)都集中在一個(gè)熱點(diǎn)表,這種情況下,并行復(fù)制會(huì)退化為單線程復(fù)制。
隨后,在MariaDB中對(duì)并行復(fù)制做了一定的改進(jìn),它的做法是:
1、主庫(kù)上能夠并行提交的事務(wù),也就是已經(jīng)進(jìn)入到了redo log commit階段的事務(wù),在從庫(kù)上也一定能夠并行提交,所以在主庫(kù)上并行提交的事務(wù),它用一個(gè)commit_id對(duì)這組事務(wù)來進(jìn)行標(biāo)識(shí),下一組并行事務(wù)的commit_id為本組的commit_id+1
2、將所有的事務(wù)的commit_id寫入binlog中
3、在從庫(kù)上應(yīng)用binlog的時(shí)候,將所有的binlog按照commit_id進(jìn)行劃分到不同的worker上
4、本組commit_id的事務(wù)全部在從庫(kù)上提交完成之后,再去拿下一批事務(wù)。
這種方法大大增加了從庫(kù)應(yīng)用relay log的速度,但是問題是從庫(kù)在應(yīng)用前一組事務(wù)的時(shí)候,后一組事務(wù)是處于等待中的,即使前一組的worker有些已經(jīng)空閑。而在主庫(kù)上,可能無時(shí)無刻不在寫入,這樣,系統(tǒng)的吞吐量上主從節(jié)點(diǎn)就不匹配,主庫(kù)的吞吐量嚴(yán)重高于從庫(kù)。
MySQL5.7的并行復(fù)制在MariaDB的基礎(chǔ)上做了改進(jìn),我們知道,事務(wù)進(jìn)入到redo log prepare階段的時(shí)候,由于WAL技術(shù),說明此時(shí)事務(wù)已經(jīng)經(jīng)過了所沖突檢測(cè)階段了。MySQL5.7的并行復(fù)制時(shí)將所有在主庫(kù)上處于redo log prepare階段的事務(wù),和該階段之后的事務(wù),也就是處于redo log commit階段的事務(wù),在從庫(kù)并行執(zhí)行,從而減少worker線程不必要的等待。
這里,有必要再說兩個(gè)參數(shù),
- binnlog_group_commit_sync_delay參數(shù),表示redo log prepare階段完成之后,延遲多少微秒后才調(diào)用fsync;
- binlog_group_commit_sync_no_delay_count參數(shù),表示累積多少次redo log prepare:write的操作以后才調(diào)用fsync
這兩個(gè)參數(shù)是用于故意拉長(zhǎng)binlog從write到fsync的時(shí)間,以此減少binlog的寫盤次數(shù)。在MySQL 5.7的并行復(fù)制策略里,它們可以用來制造更多的“同時(shí)處于prepare階段的事務(wù)”。這樣就增加了備庫(kù)復(fù)制的并行度。
它們既可以“故意”讓主庫(kù)提交得慢些,又可以讓備庫(kù)執(zhí)行得快些。在MySQL 5.7處理備庫(kù)延遲的時(shí)候,可以考慮調(diào)整這兩個(gè)參數(shù)值,來達(dá)到提升備庫(kù)復(fù)制并發(fā)度的目的。
以上就是淺析MySQL并行復(fù)制的詳細(xì)內(nèi)容,更多關(guān)于MySQL并行復(fù)制的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
解讀sql中timestamp和datetime之間的轉(zhuǎn)換
這篇文章主要介紹了解讀sql中timestamp和datetime之間的轉(zhuǎn)換方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2022-12-12MySQL中row_number的實(shí)現(xiàn)過程
這篇文章主要介紹了MySQL中row_number的實(shí)現(xiàn)過程,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-10-10Dbeaver連接MySQL數(shù)據(jù)庫(kù)及錯(cuò)誤Connection?refusedconnect處理方法
這篇文章主要介紹了dbeaver連接MySQL數(shù)據(jù)庫(kù)及錯(cuò)誤Connection?refusedconnect處理方法,本文通過圖文并茂的形式給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-08-08簡(jiǎn)單實(shí)現(xiàn)SQLServer轉(zhuǎn)MYSQL的方法
SqlServer數(shù)據(jù)轉(zhuǎn)換成mysql數(shù)據(jù),可以說是一個(gè)老生常談了,網(wǎng)上也有很多的方法,今天我們來看一種不一樣的方法,而且也非常的簡(jiǎn)單,雖然有點(diǎn)小缺陷,但還是不失為一種很好的方法,當(dāng)然如果結(jié)合mss2sql那就非常完美了2014-08-08navicat連接mysql時(shí)出現(xiàn)1045錯(cuò)誤的解決方法
這篇文章主要為大家詳細(xì)介紹了navicat連接mysql時(shí)出現(xiàn)1045錯(cuò)誤的解決方法,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-02-02MySQL中使用CTE獲取時(shí)間段數(shù)據(jù)的技巧分享
在數(shù)據(jù)庫(kù)操作中,獲取特定時(shí)間段的數(shù)據(jù)是一項(xiàng)常見任務(wù),MySQL自從8.0版本開始支持CTE(公共表表達(dá)式),使得我們可以更加靈活和高效地處理時(shí)間段數(shù)據(jù),本文小編介紹了MySQL中使用CTE獲取時(shí)間段數(shù)據(jù)的技巧分享,需要的朋友可以參考下2024-08-08MySQL遠(yuǎn)程連接丟失問題解決方法(Lost connection to MySQL server)
這篇文章主要介紹了MySQL遠(yuǎn)程連接丟失問題解決方法,Mysql錯(cuò)誤Lost connection to MySQL server at ‘reading initial communication packet’, system error: 0解決方法,需要的朋友可以參考下2014-06-06