mysql數(shù)據(jù)庫xtrabackup壓縮備份測試

發(fā)布時間：2020-08-10 17:50:38 來源：ITPUB博客閱讀：177 作者：e71hao 欄目：MySQL數(shù)據(jù)庫

網(wǎng)上有篇文章為：TB級mysql數(shù)據(jù)之xtrabackup壓縮備份遷移方案，今天自己親測下，看看效果。結(jié)論在最后給出。簡單介紹下環(huán)境：
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
不壓縮，總的文件內(nèi)容為7.8G，cpu使用中大部分時間都是”%wa“項(xiàng)目，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”項(xiàng)目，此時每秒吞吐量是：
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
按道理來說，我開啟了并發(fā)讀文件，開啟了壓縮，然并卵，沒有用

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，單線程壓縮。這個腳本的特點(diǎn)是：沒有開并發(fā)讀，采用了gzip壓縮，總的使用時間縮短到9分鐘。瓶頸應(yīng)該在壓縮。

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“項(xiàng)目。磁盤io表示毫無壓力，我不貼出來了。使用時間縮短到7分鐘。使用pigz壓縮，開了15線程壓縮，cpu跑得快冒煙了。然后我在上面語句又加了參數(shù)--parallel=8，然并卵，效果一樣，還是7分鐘。

結(jié)論：不用壓縮的時候，備份的瓶頸在io，備份的文件為7.8G，所以用時最長。使用pigz來壓縮備份，瓶頸在cpu，顯然，cpu的速度遠(yuǎn)遠(yuǎn)快與io的，所以用時最短。

向AI問一下細(xì)節(jié)

mysql數(shù)據(jù)庫xtrabackup壓縮備份測試

猜你喜歡

最新資訊

相關(guān)推薦

相關(guān)標(biāo)簽