淺析MySQL并行復(fù)制
01 并行復(fù)制的概念
在MySQL的主從復(fù)制架構(gòu)中，主庫上經(jīng)常會(huì)并發(fā)的執(zhí)行很多SQL，只要這些SQL沒有產(chǎn)生鎖等待，那么同一時(shí)間并發(fā)好幾個(gè)SQL線程是沒有問題的。
我們知道，MySQL的從庫是要通過IO_thread去拉取主庫上的binlog的，然后存入本地，落盤成relay-log，通過sql_thread來應(yīng)用這些relay-log。
在MySQL5.6之前的版本中，當(dāng)主庫上有多個(gè)線程并發(fā)執(zhí)行SQL時(shí)，sql_thread只有一個(gè)，在某些TPS比較高的場(chǎng)景下，會(huì)出現(xiàn)主庫嚴(yán)重延遲的問題。MySQL為了解決這個(gè)問題，將sql_thread演化了多個(gè)worker的形式，在slave端并行應(yīng)用relay log中的事務(wù)，從而提高relay log的應(yīng)用速度，減少復(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ù)庫進(jìn)行并行執(zhí)行relay log，這種方式能夠解決一部分問題，因?yàn)椴煌瑪?shù)據(jù)庫上的SQL，肯定不會(huì)修改表中的同一行內(nèi)容。這樣也就不會(huì)產(chǎn)生鎖爭(zhēng)用。在一些數(shù)據(jù)庫均勻分布，每個(gè)數(shù)據(jù)庫使用頻率都差不多的場(chǎng)景下，這種并行復(fù)制的方法比較好。如果你的業(yè)務(wù)的數(shù)據(jù)都集中在一個(gè)熱點(diǎn)表，這種情況下，并行復(fù)制會(huì)退化為單線程復(fù)制。
隨后，在MariaDB中對(duì)并行復(fù)制做了一定的改進(jìn)，它的做法是：
1、主庫上能夠并行提交的事務(wù)，也就是已經(jīng)進(jìn)入到了redo log commit階段的事務(wù)，在從庫上也一定能夠并行提交，所以在主庫上并行提交的事務(wù)，它用一個(gè)commit_id對(duì)這組事務(wù)來進(jìn)行標(biāo)識(shí)，下一組并行事務(wù)的commit_id為本組的commit_id+1
2、將所有的事務(wù)的commit_id寫入binlog中
3、在從庫上應(yīng)用binlog的時(shí)候，將所有的binlog按照commit_id進(jìn)行劃分到不同的worker上
4、本組commit_id的事務(wù)全部在從庫上提交完成之后，再去拿下一批事務(wù)。
這種方法大大增加了從庫應(yīng)用relay log的速度，但是問題是從庫在應(yīng)用前一組事務(wù)的時(shí)候，后一組事務(wù)是處于等待中的，即使前一組的worker有些已經(jīng)空閑。而在主庫上，可能無時(shí)無刻不在寫入，這樣，系統(tǒng)的吞吐量上主從節(jié)點(diǎn)就不匹配，主庫的吞吐量嚴(yán)重高于從庫。
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í)將所有在主庫上處于redo log prepare階段的事務(wù)，和該階段之后的事務(wù)，也就是處于redo log commit階段的事務(wù)，在從庫并行執(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ù)是用于故意拉長binlog從write到fsync的時(shí)間，以此減少binlog的寫盤次數(shù)。在MySQL 5.7的并行復(fù)制策略里，它們可以用來制造更多的“同時(shí)處于prepare階段的事務(wù)”。這樣就增加了備庫復(fù)制的并行度。
它們既可以“故意”讓主庫提交得慢些，又可以讓備庫執(zhí)行得快些。在MySQL 5.7處理備庫延遲的時(shí)候，可以考慮調(diào)整這兩個(gè)參數(shù)值，來達(dá)到提升備庫復(fù)制并發(fā)度的目的。
以上就是淺析MySQL并行復(fù)制的詳細(xì)內(nèi)容，更多關(guān)于MySQL并行復(fù)制的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
我們知道Mysql并發(fā)事務(wù)會(huì)引起更新丟失問題,解決辦法是鎖,所以本文將對(duì)鎖（樂觀鎖、悲觀鎖）進(jìn)行分析,這篇文章主要給大家介紹了關(guān)于MySQL悲觀鎖與樂觀鎖方案的相關(guān)資料,需要的朋友可以參考下2021-11-11
這篇文章主要介紹了新手如何安裝Mysql(親測(cè)有效),文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-02-02
本篇文章主要給大家詳細(xì)講解了MySQL復(fù)制優(yōu)點(diǎn)以及Mysql復(fù)制的原理知識(shí)，對(duì)此有興趣的朋友學(xué)習(xí)下。2018-02-02
關(guān)于MySQL索引的幾點(diǎn)值得注意的事項(xiàng)
索引對(duì)查詢的速度有著至關(guān)重要的影響，MySQL索引的建立對(duì)于MySQL的高效運(yùn)行是很重要的2014-07-07
這篇文章主要介紹了MySQL中如何在原有的表中增加一列問題，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2023-02-02
這篇文章主要介紹了MySQL是如何解決幻讀的，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-04-04
MySQL用戶和權(quán)限及破解root口令的方法示例
這篇文章主要介紹了詳解MySQL用戶和權(quán)限及破解root口令，小編覺得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧2019-05-05
本篇文章是對(duì)MySQL游標(biāo)的具體使用進(jìn)行了詳細(xì)的分析介紹，需要的朋友參考下2013-06-06
這篇文章主要介紹了MySQL限制查詢和數(shù)據(jù)排序介紹，通過limit可以限制返回結(jié)果的行數(shù)，而當(dāng)數(shù)據(jù)查詢出來以后，我們可以對(duì)數(shù)據(jù)進(jìn)行排序處理。在末尾使用order?by語句，下文相關(guān)詳細(xì)介紹，需要的小伙伴可以參考一下2022-03-03
MySQL日志的內(nèi)容非常重要,面試中經(jīng)常會(huì)被問到,下面這篇文章主要給大家介紹了關(guān)于Mysql數(shù)據(jù)庫中各種日志的相關(guān)資料,文中通過代碼介紹的非常詳細(xì),對(duì)大家學(xué)習(xí)或者使用mysql具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2024-08-08