start slave;
圖中使用了2個主庫：music和habit，假設(shè)music存放音樂的歌手、名稱和其他信息，habit保存了用戶的偶像、最喜歡的歌、常聽的歌、播放高峰時間段和地理位置信息的話，匯聚到從庫便可即實現(xiàn)了經(jīng)濟(jì)實惠的從庫端分庫合并又實現(xiàn)了統(tǒng)一做用戶行為分析，還可以用一條mysqldump命令加個--all-databases參數(shù)全部導(dǎo)出做備份。
考慮到多源復(fù)制運行過程中，一臺從庫要接受多方的數(shù)據(jù)，相比壓力會比單庫復(fù)制有所提升，因此需要優(yōu)化一下從庫配置，從而提升從庫執(zhí)行效率。
性能提升利器——并行復(fù)制
接下來要說的就是：性能提升利器——并行復(fù)制。 為了提高SQL線程(SQL thread)的執(zhí)行效率，減少主庫與從庫之間的延遲，MySQL提供了并行復(fù)制的特性，可以將事務(wù)在從庫上多線程并發(fā)的回放應(yīng)用，從而達(dá)到加速同步速度的效果。
需要注意的是，使用過程中還是有一些問題需要稍加留意，如果設(shè)置不當(dāng)，反而可能會畫蛇添足。
就拿性能來說，并不是并發(fā)開的越高越好，并發(fā)開的過高和過低，都可能帶來負(fù)面性能影響，比如引起Coordinator的判斷、分發(fā)等處理過程開銷升高，使用Sysbench進(jìn)行壓力測試的過程中，該開銷升高癥狀體現(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，并且在必要時自己也進(jìn)行重演操作。圖中分了18個并行，即18個worker并行工作。他們負(fù)責(zé)并行的將日志中可以劃分成一組的事務(wù)進(jìn)行并行回放。
在把事務(wù)應(yīng)用到從庫的時候，根據(jù)binary log中l(wèi)ast_committed(需設(shè)置并行類型為logical clock)的值判斷是否可以放在一組進(jìn)行并行回放，如果取值相同，便并行執(zhí)行。
日志信息：
從日志中看到，數(shù)據(jù)庫已經(jīng)開啟了GTID(全局事務(wù)標(biāo)識)功能，此功能是5.6版本出現(xiàn)的，可以保證每個提交的事務(wù)都會有一個全局唯一的編號，日志中也可看到GTID信息。
多源復(fù)制開啟并發(fā)后的架構(gòu)圖：
開啟并行復(fù)制操作的方法對于1主和多源是一樣的：
stop slave;
SET GLOBAL SLAVE_PARALLEL_TYPE='LOGICAL_CLOCK';
SET GLOBAL SLAVE_PARALLEL_WORKERS=30;
start slave;
驗證配置生效：
用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個線程進(jìn)行重演，因此與并發(fā)度設(shè)置為2很接近，所以務(wù)必注意如果想關(guān)閉并發(fā)一定要設(shè)置為0，而不是1。
接下來進(jìn)行多源復(fù)制的壓力測試與性能監(jiān)控：