mysqlpump的效能測試(r12筆記第89天)

  在MySQL 5.7中做邏輯備份恢復有了一個新的工具mysqlpump，如果你掌握了mysqldump,那麼使用mysqlpump就是分分鐘的事情，因為很多引數都是很相似的，可以理解它是mysqldump的加強版，一個亮點就是有了並行的選項，使得資料備份的效能更加強大。

  有一點值得說明的是，為了保證資料一致性，我們一般備份都會使用--single-transaction的選項，在5.7.11以前，mysqlpump和並行引數是有衝突的，在這個版本之後做了修復。

  但是mysqlpump到底怎麼樣呢，我在5.7.17的版本中做了一些簡單的測試，可以看出一些效能的差異。

   為了儘可能保證匯出的資料備份能夠佔用少的磁碟空間，我們經常會使用gzip來壓縮，我們就分了幾個場景來對比壓縮，不壓縮，開啟並行後的資料備份的效能差異。

   我選取的資料集大小在30G左右。含有5個資料庫，單表資料量在200萬以上，單庫的表數量在10個以上。

   得到的一個基本測試結果如下，後續的測試結果會一併補上。

option	real	idle%	dump_size(byte)
compress=false	6m52.232s	85.92	26199028017
compress=false|gzip	43m12.574s	90.72	12571701197
compress=true	19m24.541s	80.48	26199028017
compress=true   |gzip	43m12.515s	84.94	12571200219
parallelism=4	5m30.005s	76.43	26199028017
parallelism=4   |gzip	42m41.433s	90.51	12575331504
parallelism=8	4m44.177s	66.73	26199028017

可以看到預設來說，匯出一個30G左右的dump需要近7分鐘，而啟用了並行之後，並行度為4的時候，匯出時間是5分半，提升了1.5分鐘（20%），並行度為8之後提升了2分鐘左右（30%）。而在系統層面做了壓縮的時候，壓縮率達到了近48%。還是相當不錯的。在compress=true只是在服務端客戶端互動中使用資料包壓縮，最後的備份集大小是沒有任何改變的。後續會測試使用不同的壓縮演算法，備份的效能差異。