网上有篇文章为: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的,所以用时最短。
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的,所以用时最短。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/30393770/viewspace-2127233/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/30393770/viewspace-2127233/