本篇文章給大家主要講的是關(guān)于MySQL并行復(fù)制配置與調(diào)優(yōu)的操作的內(nèi)容，感興趣的話就一起來(lái)看看這篇文章吧，相信看完MySQL并行復(fù)制配置與調(diào)優(yōu)的操作對(duì)大家多少有點(diǎn)參考價(jià)值吧。

十年專業(yè)網(wǎng)站制作公司歷程，堅(jiān)持以創(chuàng)新為先導(dǎo)的網(wǎng)站服務(wù)，服務(wù)超過(guò)成百上千家企業(yè)及個(gè)人，涉及網(wǎng)站設(shè)計(jì)、重慶APP開發(fā)公司、微信開發(fā)、平面設(shè)計(jì)、互聯(lián)網(wǎng)整合營(yíng)銷等多個(gè)領(lǐng)域。在不同行業(yè)和領(lǐng)域給人們的工作和生活帶來(lái)美好變化。

并行復(fù)制產(chǎn)生的背景：
因?yàn)镮/O thread和SQL thread是單線程工作的，而Master是可以多線程寫入的，所以主從難免造成延遲
基于此，在5.6，5.7，8.0版本都在SQL線程上實(shí)現(xiàn)了多線程，來(lái)提升slave的并發(fā)度

為什么不是I/O多線程？
I/O沒(méi)必要多線程，因?yàn)镮/O線程并不是瓶頸啊 （沒(méi)怎么理解）

并行復(fù)制的目的：
讓Slave SQL線程盡可能以多線程工作，解決復(fù)制延遲的問(wèn)題

并行復(fù)制實(shí)現(xiàn)的前提：
能夠進(jìn)行并行復(fù)制，關(guān)鍵在于多事務(wù)之間是否有鎖沖突

MySQL5.6基于schema的并行復(fù)制：
應(yīng)用場(chǎng)景：
比較適用于一個(gè)庫(kù)中有多個(gè)schema的場(chǎng)景

并行復(fù)制的原理：
MySQL5.6開啟并行復(fù)制功能后，SQL線程變成coordinator線程，由其判斷是否可以并發(fā)執(zhí)行，這意味著一個(gè)worker線程可以處理一個(gè)數(shù)據(jù)庫(kù)的連續(xù)事務(wù)，而不用等待其它數(shù)據(jù)庫(kù)完成
如果可以并行執(zhí)行，選擇worker線程執(zhí)行二進(jìn)制日志
如果不可以并行執(zhí)行，如：DDL或者跨schema操作，則等待所有的worker線程執(zhí)行完成之后再執(zhí)行當(dāng)前日志

摘自網(wǎng)上的一張圖片，供參考理解：

基于schema的并行復(fù)制帶來(lái)的問(wèn)題：
因?yàn)镸ySQL5.6并行復(fù)制只是基于schema，但對(duì)于單庫(kù)多表的復(fù)制場(chǎng)景是無(wú)法實(shí)現(xiàn)的，甚至性能可能還達(dá)不到原來(lái)的單線程復(fù)制，而在實(shí)際工作中單庫(kù)多表比多庫(kù)多表的場(chǎng)景更為常見。
MySQL5.6基于schema級(jí)別的并發(fā)復(fù)制可以解決業(yè)務(wù)表放在不同的DATABASE下同步延遲的問(wèn)題，但是在實(shí)際生產(chǎn)中大部分表還是放在同一個(gè)庫(kù)中的，這種情況即使設(shè)置slave_parallel_workers大于0，也無(wú)法進(jìn)行并發(fā)。在高并發(fā)的情況下，依然會(huì)造成主從復(fù)制延遲

MySQL5.6并行復(fù)制開啟：（前提是配置好主從復(fù)制環(huán)境）

mysql> stop slave;

Query OK, 0 rows affected (0.03 sec)

mysql> set global slave_parallel_workers=8;

Query OK, 0 rows affected (0.05 sec)

mysql> start slave;

Query OK, 0 rows affected, 1 warning (0.07 sec)

MySQL5.6并行復(fù)制原理圖：

并行復(fù)制參數(shù)說(shuō)明：

slave_parallel_workers:
Number of applier threads for executing replication transactions in parallel. A value of 0 disables slave multithreading. Not supported by MySQL Cluster

MySQL5.7并行復(fù)制原理：
基于組復(fù)制（group commit）實(shí)現(xiàn)

如何知道事務(wù)是否在同一組中？
在MySQL 5.7版本中，其設(shè)計(jì)方式是將組提交的信息存放在GTID中。那么如果用戶沒(méi)有開啟GTID功能，即：將參數(shù)gtid_mode設(shè)置為OFF呢？
MySQL 5.7引入了稱之為Anonymous_Gtid（ANONYMOUS_GTID_LOG_EVENT）的二進(jìn)制日志event類型，組提交信息存放在 Anonymous_Gtid 中。

當(dāng)開啟GTID時(shí)，每一個(gè)操作語(yǔ)句（DML/DDL）執(zhí)行前就會(huì)添加一個(gè)GTID事件，記錄當(dāng)前全局事務(wù)ID；同時(shí)在MySQL 5.7版本中，組提交信息也存放在GTID事件中，有兩個(gè)關(guān)鍵字段last_committed，sequence_number就是用來(lái)標(biāo)識(shí)組提交信息的。在InnoDB中有一個(gè)全局計(jì)數(shù)器（global counter），在每一次存儲(chǔ)引擎提交之前，計(jì)數(shù)器值就會(huì)增加。在事務(wù)進(jìn)入prepare階段之前，全局計(jì)數(shù)器的當(dāng)前值會(huì)被儲(chǔ)存在事務(wù)中，這個(gè)值稱為此事務(wù)的commit-parent（也就是last_committed）。last_committed表示事務(wù)提交的時(shí)候，上次事務(wù)提交的編號(hào)，如果事務(wù)具有相同的last_committed，表示這些事務(wù)都在一組內(nèi)，可以進(jìn)行并行的回放。而sequence_number是順序增長(zhǎng)的，每個(gè)事務(wù)對(duì)應(yīng)一個(gè)序列號(hào)。

這意味著在MySQL 5.7版本中即使不開啟GTID，每個(gè)事務(wù)開始前也是會(huì)存在一個(gè)Anonymous_Gtid，而這個(gè)Anonymous_Gtid事件中就存在著組提交的信息。反之，如果開啟了GTID后，就不會(huì)存在這個(gè)Anonymous_Gtid了，從而組提交信息就記錄在非匿名GTID事件中。

MySQL如何將這些事務(wù)進(jìn)行分組的？
一個(gè)組提交的事務(wù)都是可以并行回放，因?yàn)檫@些事務(wù)都已進(jìn)入到事務(wù)的prepare階段，則說(shuō)明事務(wù)之間沒(méi)有任何沖突（否則就不可能提交）

MySQL5.7并行復(fù)制簡(jiǎn)介：
1）MySQL 5.7才可稱為真正的并行復(fù)制，這其中最為主要的原因就是slave云服務(wù)器的回放與master是一致的，即master云服務(wù)器上是怎么并行執(zhí)行的，那么slave上就怎樣進(jìn)行并行回放。不再有庫(kù)的并行復(fù)制限制，對(duì)于二進(jìn)制日志格式也無(wú)特殊的要求（基于庫(kù)的并行復(fù)制也沒(méi)有要求）
2）MySQL5.7并行復(fù)制支持表級(jí)
3）Enhanced Multi-threaded Slaves（MTS）

MySQL5.7并行復(fù)制參數(shù)：
SHOW VARIABLES LIKE 'slave_parallel_%'
Variable_name      Value
slave_parallel_type DATABASE （變量slave-parallel-type可以有兩個(gè)值：DATABASE 默認(rèn)值，基于庫(kù)的并行復(fù)制方式；LOGICAL_CLOCK：基于組提交的并行復(fù)制方式（基于表））
slave_parallel_workers     0

MySQL 5.7并行復(fù)制配置與調(diào)優(yōu)：
# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
slave_preserve_commit_order=1
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

MySQL5.7在線開啟并行復(fù)制（多線程復(fù)制）：
參考視頻：https://www.imooc.com/video/10921

在Slave云服務(wù)器上停止所有鏈路的復(fù)制

stop slave
set global slave-parallel-type=LOGICAL_CLOCK
set global slave-parallel-workers=16
start slave
show processlist（看到16個(gè)SQL線程）

MySQL5.7應(yīng)用事務(wù)順序和realy log記錄事務(wù)順序不一樣的問(wèn)題：
MySQL 5.7后的MTS可以實(shí)現(xiàn)更小粒度的并行復(fù)制，但需要將slave_parallel_type設(shè)置為L(zhǎng)OGICAL_CLOCK，但僅僅設(shè)置為L(zhǎng)OGICAL_CLOCK也會(huì)存在問(wèn)題，因?yàn)榇藭r(shí)在slave上應(yīng)用事務(wù)的順序是無(wú)序的，和relay log中記錄的事務(wù)順序不一樣，這樣數(shù)據(jù)一致性是無(wú)法保證的，為了保證事務(wù)是按照relay log中記錄的順序來(lái)回放，就需要開啟參數(shù)slave_preserve_commit_order

以上關(guān)于MySQL并行復(fù)制配置與調(diào)優(yōu)的操作詳細(xì)內(nèi)容，對(duì)大家有幫助嗎？如果想要了解更多相關(guān)，可以繼續(xù)關(guān)注我們的行業(yè)資訊板塊。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)頁(yè)標(biāo)題：MySQL并行復(fù)制配置與調(diào)優(yōu)的操作-創(chuàng)新互聯(lián)
本文地址：http://www.rwnh.cn/article42/epihc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、面包屑導(dǎo)航、搜索引擎優(yōu)化、手機(jī)網(wǎng)站建設(shè)、電子商務(wù)、微信公眾號(hào)

廣告

聲明：本網(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í)需注明來(lái)源： 創(chuàng)新互聯(lián)