復(fù)制技術(shù)顧名思義，就是通過數(shù)據(jù)庫的復(fù)制技術(shù)以一份數(shù)據(jù)為主,，復(fù)制成另一份存放,，數(shù)據(jù)來源的那一份做為主庫，存放復(fù)制數(shù)據(jù)的的稱為從庫,。MySQL的復(fù)制方案有很多,，比如主從復(fù)制、半同步復(fù)制,、多主還有主主復(fù)制等,。基本都是是通過把主庫的操作寫入二進制日志,，將二進制日志傳送到從庫并且重演日志中記錄的操作跟進主庫狀態(tài)以便達到在從庫數(shù)據(jù)同步的效果,。

其中，主從復(fù)制可以變換,、擴展出很多的組合方法,，比如多源復(fù)制（多臺master將數(shù)據(jù)發(fā)送到1臺數(shù)據(jù)庫）、1主多從或者還有從服務(wù)器再延伸出從服務(wù)器,。

下面列舉一些數(shù)據(jù)庫主從復(fù)制架構(gòu)：

注：主庫為Master（1,2,..,N）,，從庫為Slave(1,2,...,N)。

主從復(fù)制有如下一些優(yōu)勢：

從MySQL的5.7版本開始支持多源主從復(fù)制技術(shù)（Multi-Source Replication）,，就是將多個數(shù)據(jù)庫（Master）的數(shù)據(jù)集中發(fā)送到1臺從庫（Slave）上,，該技術(shù)也具有剛才上文提到的主從復(fù)制的優(yōu)勢，除了這些,，它的獨特性還在于：

下面咱們先循序漸進簡單了解一下基本的1主1從（1 master,，1 slave）復(fù)制的實現(xiàn)過程：

圖中Master為主庫的主機名，Slave為從庫主機名,。同步的數(shù)據(jù)庫名為Music,。從庫接收主庫（binlog dump線程）發(fā)過來的Binary Log，通過從庫的I/O線程（I/O thread）將日志寫入從庫的Relay Log中,，然后通過SQL線程（SQL thread）將日志的內(nèi)容應(yīng)用到從庫中,。

在從庫上通過命令可以看到2個必備進程(I/O thread和SQL thread)在待命狀態(tài)，線程狀態(tài)如下：

線程的功能主要通過state字段確認(rèn)：

開啟并發(fā)后還會有以下線程：

多源復(fù)制的實現(xiàn)與1主1從的類似,，都是發(fā)送二進制日志再重演,，但是在SQL線程（SQL thread）上有略微區(qū)別，會為每個主庫實例提供一套SQL和IO線程：

多源復(fù)制的配置比較簡單：

圖中使用了2個主庫：music和habit,，假設(shè)music存放音樂的歌手,、名稱和其他信息，habit保存了用戶的偶像,、最喜歡的歌,、常聽的歌、播放高峰時間段和地理位置信息的話,，匯聚到從庫便可即實現(xiàn)了經(jīng)濟實惠的從庫端分庫合并又實現(xiàn)了統(tǒng)一做用戶行為分析,，還可以用一條mysqldump命令加個--all-databases參數(shù)全部導(dǎo)出做備份。

考慮到多源復(fù)制運行過程中,，一臺從庫要接受多方的數(shù)據(jù),，相比壓力會比單庫復(fù)制有所提升，因此需要優(yōu)化一下從庫配置,，從而提升從庫執(zhí)行效率,。

接下來要說的就是：性能提升利器——并行復(fù)制。為了提高SQL線程（SQL thread）的執(zhí)行效率,，減少主庫與從庫之間的延遲,，MySQL提供了并行復(fù)制的特性,，可以將事務(wù)在從庫上多線程并發(fā)的回放應(yīng)用，從而達到加速同步速度的效果,。

需要注意的是,，使用過程中還是有一些問題需要稍加留意，如果設(shè)置不當(dāng),，反而可能會畫蛇添足,。

就拿性能來說，并不是并發(fā)開的越高越好,，并發(fā)開的過高和過低,，都可能帶來負(fù)面性能影響，比如引起Coordinator的判斷,、分發(fā)等處理過程開銷升高,，使用Sysbench進行壓力測試的過程中，該開銷升高癥狀體現(xiàn)在CPU消耗高,?？赡茉诓煌沫h(huán)境和業(yè)務(wù)場景下都會有相應(yīng)的反應(yīng)，需要量體裁衣,、因地制宜,。

下圖為1主1從SQL線程并行復(fù)制回放過程：

圖2中，SQL線程（SQL thread）由原來的1個,，分裂變成了1個Coordinator和N個worker,。Coordinator主要用來分發(fā)工作給不同的worker，并且在必要時自己也進行重演操作,。圖中分了18個并行,，即18個worker并行工作。他們負(fù)責(zé)并行的將日志中可以劃分成一組的事務(wù)進行并行回放,。

在把事務(wù)應(yīng)用到從庫的時候,，根據(jù)binary log中l(wèi)ast_committed（需設(shè)置并行類型為logical clock）的值判斷是否可以放在一組進行并行回放，如果取值相同,，便并行執(zhí)行,。

日志信息：

從日志中看到，數(shù)據(jù)庫已經(jīng)開啟了GTID（全局事務(wù)標(biāo)識）功能,，此功能是5.6版本出現(xiàn)的,，可以保證每個提交的事務(wù)都會有一個全局唯一的編號，日志中也可看到GTID信息,。

多源復(fù)制開啟并發(fā)后的架構(gòu)圖：

開啟并行復(fù)制操作的方法對于1主和多源是一樣的：

驗證配置生效：

用show processlist命令會看到會出現(xiàn)多個coordinator線程和每個co線程所分配的30個worker線程,，總共60多個線程,。（由于worker陣容太龐大,，超占篇幅,，就不在此展示了）

為什么選擇并行度為30，原因是從1主1從的測試中發(fā)現(xiàn)該并行度在本次測試環(huán)境中磁盤資源利用率略高于其他場景,，CPU消耗相對比較低,，內(nèi)存消耗差別不大，總體效率最高,，執(zhí)行時間最短,。

1主1從復(fù)制時Slave數(shù)據(jù)庫的CPU性能狀態(tài)特征：

CPU性能統(tǒng)計：

從圖中可以看到，在本次測試環(huán)境中,，CPU狀態(tài)最好的是并發(fā)度為18和30的時候,，并發(fā)度為300的時候CPU反而消耗明顯；并發(fā)為2的時候cpu消耗高,，并且處理時間更耗時,；并發(fā)為0的時候，其實等于不并發(fā),，CPU利用率不高,，耗時也較長；值得關(guān)注的是,，并發(fā)度設(shè)置為1的時候,，即使只有1個worker，但是畢竟是并發(fā)模式,，此時同樣在消耗coordinator的資源,，并且此時coordinator也參與了重演操作，相當(dāng)于2個線程進行重演,，因此與并發(fā)度設(shè)置為2很接近,，所以務(wù)必注意如果想關(guān)閉并發(fā)一定要設(shè)置為0，而不是1,。

接下來進行多源復(fù)制的壓力測試與性能監(jiān)控：

多源復(fù)制的壓力測試使用了Sysbench對2臺主庫（master和master1）一起加壓,，同時對從庫slave進行性能監(jiān)控。（3個數(shù)據(jù)庫所在的服務(wù)器配置完全相同）

測試語句：

參數(shù)說明：

考慮到30并發(fā)度的資源利用相對充分,、執(zhí)行效率相對較高的測試結(jié)果,，在從庫開啟30個SQL線程并行后進行測試，并將從庫的監(jiān)控數(shù)據(jù)進行統(tǒng)計做成可視化曲線圖進行分析,。

從下面3張測試后生成的曲線圖可以看到,，對于從主庫發(fā)過來的2萬個請求，并行執(zhí)行的完成時間（橫軸為時間）比單線程更短,，資源利用率更高,，執(zhí)行效率更高。

CPU使用率：

從圖中可看到,，開啟并行之后,，CPU的利用率比之前有所升高,，負(fù)載還OK，最高36%左右,，利用較單線程更充分,，操作完成時間更早（曲線最先恢復(fù)下降到0）。

Disk Write KB/s

硬盤使用率從圖中看出,，并行SQL線程relay過程相對比較平穩(wěn),，未出現(xiàn)明顯抖動，并且30并發(fā)的曲線最早歸零,，結(jié)束操作,。

Free Memory 剩余內(nèi)存：

內(nèi)存使用差不太多。

由此可見,，多源復(fù)制在合理的開啟并行之后,，有助于提高復(fù)制效率，縮短數(shù)據(jù)的延遲,。

總體說來,，MySQL的多源復(fù)制提供了更經(jīng)濟、方便和安全的數(shù)據(jù)庫環(huán)境,。如有感興趣的朋友,，歡迎留言一起交流，模擬業(yè)務(wù)場景進行測試,、提出測試建議,、更正錯誤和共同研究都是非常歡迎的，希望與大家互助共進,！