一、緣由：

　　某天看到主從復(fù)制延時的告警有點頻繁，就想著是不是徹底可以解決一下。

　　一般主從復(fù)制，有三個線程參與，都是單線程：Binlog Dump（主） ----->IO Thread （從） -----> SQL Thread（從）。復(fù)制出現(xiàn)延遲一般出在兩個地方

1）SQL線程忙不過來（可能需要應(yīng)用數(shù)據(jù)量較大，可能和從庫本身的一些操作有鎖和資源的沖突；主庫可以并發(fā)寫，SQL線程不可以；主要原因）

2）網(wǎng)絡(luò)抖動導(dǎo)致IO線程復(fù)制延遲（次要原因）。

?

二、解決辦法：

　　MySQL從5.6開始有了SQL Thread多個的概念，可以并發(fā)還原數(shù)據(jù)，即并行復(fù)制技術(shù)。

　　MySQL 5.6中，設(shè)置參數(shù)slave_parallel_workers = 4(>1)，即可有4個SQL Thread（coordinator線程）來進行并行復(fù)制，其狀態(tài)為：Waiting for an evant from Coordinator。

但是其并行只是基于Schema的，也就是基于庫的。如果數(shù)據(jù)庫實例中存在多個Schema，這樣設(shè)置對于Slave復(fù)制的速度可以有比較大的提升。通常情況下單庫多表是更常見的一種情形，

那基于庫的并發(fā)就沒有卵用。其核心思想是：不同schema下的表并發(fā)提交時的數(shù)據(jù)不會相互影響，即slave節(jié)點可以用對relay log中不同的schema各分配一個類似SQL功能的線程，

來重放relay log中主庫已經(jīng)提交的事務(wù)，保持數(shù)據(jù)與主庫一致。

　　在MySQL 5.7中，引入了基于組提交的并行復(fù)制（Enhanced Multi-threaded Slaves），設(shè)置參數(shù)slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’，

即可支持一個schema下，slave_parallel_workers個的worker線程并發(fā)執(zhí)行relay log中主庫提交的事務(wù)。其核心思想：一個組提交的事務(wù)都是可以并行回放（配合binary log group commit）；

slave機器的relay log中?last_committed相同的事務(wù)（sequence_num不同）可以并發(fā)執(zhí)行。

　　其中，變量slave-parallel-type可以有兩個值：DATABASE 默認值，基于庫的并行復(fù)制方式；LOGICAL_CLOCK：基于組提交的并行復(fù)制方式

MySQL 5.7開啟Enhanced Multi-Threaded Slave配置：

#?slaveslave-parallel-type=LOGICAL_CLOCKslave-parallel-workers=16master_info_repository=TABLErelay_log_info_repository=TABLErelay_log_recovery=ON

?

至此，MySQL徹底解決了復(fù)制延遲問題，可喜可賀！

?

三、參考文檔

　　官方文檔：https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html

　　Inside君的文章：http://www.ttlsa.com/mysql/mysql-5-7-enhanced-multi-thread-salve/

本文出自http://www.cnblogs.com/langdashu/p/6125621.html

轉(zhuǎn)載于:https://blog.51cto.com/lookingdream/1909338

總結(jié)

以上是生活随笔為你收集整理的MySQL5.7号称永久解决了复制延迟问题的并行复制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。