网上有篇文章为：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压缩备份测试
URL链接：http://kswjz.com/article/psjcgh.html