网上有篇文章为：TB级mysql数据之xtrabackup压缩备份迁移方案，今天自己亲测下，看看效果。结论在最后给出。简单介绍下环境：
win7下安装的vmware linuxCentOS release 6.5 (Final) x86_64 ,
mysql5.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
使用时间如下：
real12m3.511s
user0m13.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
使用时间：
real12m51.665s
user0m34.527s
sys 1m53.238s
上面语句备份出来是6.2G，大部分是“%wa”项目，此时每秒吞吐量是：
Device:tpsMB_read/sMB_wrtn/sMB_readMB_wrtn
sda0.50 0.00 0.01 0 0
sdb 106.5018.3210.56 73 42
dm-02713.7518.2010.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
real9m16.808s
user6m50.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
real6m59.320s
user17m57.191s
sys 1m3.678s
压缩后文件为4.4G，8个线程压缩，cpu使用中大部分时间都是”%us“项目。磁盘io表示毫无压力，我不贴出来了。使用时间缩短到7分钟。使用pigz压缩，开了15线程压缩，cpu跑得快冒烟了。然后我在上面语句又加了参数--parallel=8，然并卵，效果一样，还是7分钟。

结论：不用压缩的时候，备份的瓶颈在io，备份的文件为7.8G，所以用时最长。使用pigz来压缩备份，瓶颈在cpu，显然，cpu的速度远远快与io的，所以用时最短。