多源復(fù)制的壓力測試使用了Sysbench對2臺主庫(master和master1)一起加壓，同時對從庫slave進行性能監(jiān)控。(3個數(shù)據(jù)庫所在的服務(wù)器配置完全相同)
測試語句：
參數(shù)說明：
OLTP場景
Innodb引擎
對5張表操作
每數(shù)據(jù)庫1萬個操作請求(一共2萬個操作請求)
混合讀寫
每數(shù)據(jù)庫100并發(fā)
每表20萬條數(shù)據(jù)
考慮到30并發(fā)度的資源利用相對充分、執(zhí)行效率相對較高的測試結(jié)果，在從庫開啟30個SQL線程并行后進行測試，并將從庫的監(jiān)控數(shù)據(jù)進行統(tǒng)計做成可視化曲線圖進行分析。
從下面3張測試后生成的曲線圖可以看到，對于從主庫發(fā)過來的2萬個請求，并行執(zhí)行的完成時間(橫軸為時間)比單線程更短，資源利用率更高，執(zhí)行效率更高。
CPU 使用率：
從圖中可看到，開啟并行之后，CPU的利用率比之前有所升高，負載還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ù)的延遲。
小結(jié)
總體說來，MySQL的多源復(fù)制提供了更經(jīng)濟、方便和安全的數(shù)據(jù)庫環(huán)境。如有感興趣的朋友，歡迎留言一起交流，模擬業(yè)務(wù)場景進行測試、提出測試建議、更正錯誤和共同研究都是非常歡迎的，希望與大家互助共進!