網上有篇文章為：TB級mysql資料之xtrabackup壓縮備份遷移方案，今天自己親測下，看看效果。結論在最後給出。簡單介紹下環境：
win7下安裝的vmware linux CentOS release 6.5 (Final) x86_64 ,
mysql 5.6.32
xtrabackup version 2.2.12 based on MySQL server 5.6.24 Linux (x86_64)
mysql 庫為11.6G
1.第一指令碼為：
time innobackupex --defaults-file=/usr/local/mysql/my.cnf --parallel=10 --compress-threads=10 --user='xtrabk' --password='123456' /tmp/backup1
使用時間如下：
real 12m3.511s
user 0m13.338s
sys 0m53.715s
不壓縮，總的檔案內容為7.8G，cpu使用中大部分時間都是”%wa“專案，io吞吐量為40m/sec.可以看出瓶頸在I/O.

2.第二個測試指令碼為：
time innobackupex --defaults-file=/usr/local/mysql/my.cnf --parallel=8 --user='xtrabk' --password='123456' --socket=/tmp/mysql.sock --compress-threads=8 --stream=xbstream --compress /tmp > /tmp/backup1/backup4tpcc1000.tar
使用時間：
real 12m51.665s
user 0m34.527s
sys 1m53.238s
上面語句備份出來是6.2G，大部分是“%wa”專案，此時每秒吞吐量是：
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
sda 0.50 0.00 0.01 0 0
sdb 106.50 18.32 10.56 73 42
dm-0 2713.75 18.20 10.31 72 41
按道理來說，我開啟了併發讀檔案，開啟了壓縮，然並卵，沒有用

3.第三個指令碼為：
time innobackupex --defaults-file=/usr/local/mysql/my.cnf --user='xtrabk' --password='123456' --stream=tar --socket=/tmp/mysql.sock /tmp | gzip -> /tmp/backup1/backuptpcc1000.tar.gz
real 9m16.808s
user 6m50.564s
sys 0m36.050s
壓縮後檔案問4.5G，單執行緒壓縮。這個指令碼的特點是：沒有開併發讀，採用了gzip壓縮，總的使用時間縮短到9分鐘。瓶頸應該在壓縮。

4.第四個指令碼：
time innobackupex --defaults-file=/usr/local/mysql/my.cnf --user='xtrabk' --password='123456' --stream=tar --socket=/tmp/mysql.sock /tmp | pigz -8 -p 15 > /tmp/backup1/backup2tpcc1000.tar.gz
real 6m59.320s
user 17m57.191s
sys 1m3.678s
壓縮後檔案為4.4G，8個執行緒壓縮，cpu使用中大部分時間都是”%us“專案。磁碟io表示毫無壓力，我不貼出來了。使用時間縮短到7分鐘。使用pigz壓縮，開了15執行緒壓縮，cpu跑得快冒煙了。然後我在上面語句又加了引數--parallel=8，然並卵，效果一樣，還是7分鐘。

結論：不用壓縮的時候，備份的瓶頸在io，備份的檔案為7.8G，所以用時最長。使用pigz來壓縮備份，瓶頸在cpu，顯然，cpu的速度遠遠快與io的，所以用時最短。

mysql資料庫xtrabackup壓縮備份測試

相關文章