昨天花了點時間整理了下並行複製在5.6,5.7中的一些差別和測試，MySQL 5.6, 5.7並行複製測試(r12筆記第9天),當然只是一個開始，因為裡面還有不少需要完善的部分，總體的感覺來看MySQL 5.7裡的並行複製改進很大，能夠極大提高效率，充分利用資源。

那我們來簡單回顧一下MySQL的複製裡的一些事情，然後繼續展開測試。

首先借丁奇大師總結的一個經典的主從複製的流程圖來展開。

整個複製的流程中，看似存在多個節點會存在延遲的可能，而如果把這些工作都細化，那麼就會有一個很本質的原因，那就是在主庫端的更新是多執行緒，而從庫端更新是單執行緒。

這樣一個看似“存在即合理”方案在MySQL 5.6以前都是這麼做的。最早的複製和statement格式做鬥爭，過了改進，有了row格式，也算是複製方向上的一大改進，而在MySQL 5.6中引入了並行複製，這一點能夠緩和原本的複製瓶頸。

但是複製的效率提升不是嚴格意義上質的飛躍，算是一個開篇，因為支援的是資料庫級別的，如果直接多執行緒是否可以，這個按理說是一個很常規的思路，為什麼MySQL遲遲沒有推出好的方案來。

多執行緒存在一些待解決的難題，其中之一就是語句的順序無法保證，無論如何，日誌都是需要順序寫，在源端是多執行緒併發操作，而對映到日誌中，必然是一個順序的記錄方式，而這個操作到了從庫，也只能老老實實的按照順序來應用，如果採用多執行緒就得尤其注意這個順序，我們可以逐步來細分，首先對於同一個表的更新只能按照順序來同步，而這個粒度可以逐步細分，比如資料庫級，表級等，目前MySQL 5.6中是按照資料庫級來做的，當然這個粒度還是有些粗。在5.7就全面改進了。

當然我們在開始具體的測試之前，我簡單說一下我們量血壓的場景，一般都會有一個收縮壓，舒張壓的指標，對於主從複製而言，我突然想到了這一點，我覺得還是有可以借鑑的地方。

比如我昨天測試的而一個圖，是MySQL 5,6,5.7單執行緒，多執行緒的延遲對比圖。

其實這個圖我感覺沒有畫完，因為大批量的事務併發處理，必然會導致延遲，比如有10分鐘的高強度併發，那麼10分鐘後延遲不是立即消失的，從庫得慢慢消化這個延遲的資料，這個時間我們也需要關注，至於主從一致後的延遲迴落到底是什麼樣，我想只是看這個圖可能還看不出個所以然，所以想到了這一點，我就繼續補充了一下測試的場景，調整了時間。

下面這個圖花了我不少的時間去收集資料，整理。

中間紅色的箭頭就是在指定的時間範圍的加壓測試，而右邊的部分則是延遲迴落的一個過程，可以很清晰的看到，對於從庫的延遲在加壓完成後，延遲依舊會逐步增長，達到一個峰值後，迅速回落，回落的過程來看，MySQL 5.6中的單執行緒，多執行緒，和MySQL 5.7中的測試情況大體相似，從耗時情況和延遲迴落的趨勢，基本都是相似的，而MySQL 5.7的並行複製相比而言就是一個亮點，資料加壓後的延遲迴落極快，整個過程耗時要低很多。

當然這個圖例也反映出來一些問題，那就是MySQL 5.6的單執行緒和多執行緒的結果幾乎一樣，這就對了，這就錯了。對了是由此可以看出在這個測試場景中，並行複製沒有派上用場，錯了的原因是測試的場景還可以繼續改進，可以更有針對性。

怎麼改進呢，因為5.6中是資料庫級的複製，所以我們可以建立多個數據庫，然後在從庫開啟並行複製來改進，對比測試。

怎麼能夠快速看到一個效果呢。

我們繼續開啟sysbench的加壓測試，使用pt工具同步檢測延遲，花幾分鐘就可以看出差別來，比如我們首先建立4個數據庫，每個資料庫下建立10個表。

mysqladmin create sysbenchtest1

初始化一部分資料，對於sysbenchtest1如此，其它的幾個資料庫也是類似的操作。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3307 --mysql-socket=/home/mysql_5.6.23/mysql.sock --mysql-host=localhost --mysql-db=sysbenchtest1 --tables=10 --table-size=2000000 --threads=30 prepare

然後開啟sysbench測試。

sysbench /home/sysbench/sysbench-1.0.3/src/lua/oltp_read_write.lua --mysql-user=root --mysql-port=3307 --mysql-socket=/home/mysql_5.6.23/mysql.sock --mysql-host=localhost --mysql-db=sysbenchtest1 --tables=10 --table-size=2000000 --threads=30 --time=300 run

檢視延遲的情況：

pt-heartbeat h='10.127.128.78',u='pt_checksum',p='pt_checksum',P=3307 -D sysbenchtest --table=heartbeat --monitor --master-server-id=3307 --frames=5s --interval=5

幾個簡單的對比就可以說明。

開啟並行複製模式時，延遲如下：

0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ]

然後修改引數slave_parallel_workers為0，切換回單執行緒模式，延遲開始加大。

1.00s [ 0.20s ] 0.00s [ 0.20s ] 2.00s [ 0.60s ] 0.00s [ 0.60s ] 1.00s [ 0.80s ] 0.00s [ 0.60s ] 0.00s [ 0.60s ] 0.00s [ 0.20s ] 0.00s [ 0.20s ] 1.00s [ 0.20s ]

再次切換回並行複製模式，延遲逐漸減低，並回復平穩。

0.00s [ 0.40s ] 0.00s [ 0.20s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.00s ] 0.01s [ 0.00s ] 0.00s [ 0.00s ] 0.00s [ 0.20s ] 0.00s [ 0.20s ]

當然想看到更加細緻的圖形對比，也不是一件難的事情，得容我花點時間收集下資料，給出一個詳細的對比報告。