mysqldump与mydumper对比测试

1 引言

　　mysqldump是mysql官方自带的备份工具，是一个很好用的mysql数据转移工具，具备兼容强强、跨版本等特色

　　mydumper是一个针对MySQL的高性能多线程备份和恢复工具，它提供了并发备份功能，备份效率有很大提升，而且按照单表进行备份，表恢复更加方便。

　　mydumper主要特性有：

       • 轻量级C语言写的

       • 执行速度比mysqldump快10倍

       • 事务性和非事务性表一致的快照(适用于0.2.2以上版本)

       • 快速的文件压缩

       • 支持导出binlog

       • 多线程恢复(适用于0.2.1以上版本)

       • 以守护进程的工做方式，定时快照和连续二进制日志(适用于0.5.0以上版本)

       • 开源 (GNU GPLv3)

　　本文将对两个工具进行简单的对比测试，并给出参考结果。

2 安装及使用方式

因为mysqldump使用较多，比较熟悉，因此这里主要介绍mydumper的安装使用。

2.1 Mydumper安装

Mydumper下载地址：https://launchpad.net/mydumper，最新的稳定版本是0.6.2，下载以后按照以下方式安装：      

1 # yum install glib2-devel mysql-devel zlib-devel pcre-devel gcc-c++
2 # wget http://launchpad.net/mydumper/0.6/0.6.2/+download/mydumper-0.6.2.tar.gz
3 # tar zxvf mydumper-0.6.2.tar.gz
4 # cd mydumper-0.6.2
5 # cmake .
6 # make
7 # make install

 

2.2 mydumper 经常使用参数

　　mydumper安装完成以后包括导出的mydumper工具和导入的myloader，主要参数以下：

 mydumper参数介绍：
         -B, --database 须要备份的库
         -T, --tables-list 须要备份的表，用，分隔
         -o, --outputdir 输出目录
         -s, --statement-size Attempted size of INSERT statement in bytes, default 1000000
         -r, --rows 试图分裂成不少行块表
         -c, --compress 压缩输出文件
         -e, --build-empty-files 即便表没有数据，仍是产生一个空文件
         -x, --regex 支持正则表达式
         -i, --ignore-engines 忽略的存储引擎，用，分隔
         -m, --no-schemas 不导出表结构
         -k, --no-locks 不执行临时共享读锁 警告：这将致使不一致的备份
         -l, --long-query-guard 长查询，默认60s
         --kill-long-queries kill掉长时间执行的查询(instead of aborting)
         -b, --binlogs 导出binlog
         -D, --daemon 启用守护进程模式
         -I, --snapshot-interval dump快照间隔时间，默认60s，须要在daemon模式下
         -L, --logfile 日志文件
         -h, --host
         -u, --user
         -p, --password
         -P, --port
         -S, --socket
         -t, --threads 使用的线程数，默认4
         -C, --compress-protocol 在mysql链接上使用压缩
         -V, --version
         -v, --verbose 更多输出, 0 = silent, 1 = errors, 2 = warnings, 3 = info, default 2


myloader参数介绍：
         -d, --directory 导入备份目录
         -q, --queries-per-transaction 每次执行的查询数量, 默认1000
         -o, --overwrite-tables 若是表存在删除表
         -B, --database 须要还原的库
         -e, --enable-binlog 启用二进制恢复数据
         -h, --host
         -u, --user
         -p, --password
         -P, --port
         -S, --socket
         -t, --threads 使用的线程数量，默认4
         -C, --compress-protocol 链接上使用压缩
         -V, --version
         -v, --verbose 更多输出, 0 = silent, 1 = errors, 2 = warnings, 3 = info, default 2     

 

 

2.3 使用例子

2.3.1 导出数据库备份

　　mydumper备份时须要指定一个备份目录，不能像mysqldump同样备份整个库指定到某个特定的sql文件：

1 mydumper -u root -p ${MYSQLPASSWD}  -B ${DB_NAME} -o ${BACKUPDIR} -t 4

 

　　导出的文件以下图所示：

 

　　每一个代表后接schema的sql文件的是表结构文件，另外一个是表数据，若是表没有数据默认只有一个schema的文件，能够加上-e参数强制生成一个空的数据文件。若是加上-c参数就会对每一个导出的文件进行压缩打包，以下图所示：

 

2.3.2 导入数据库备份

1 myloader -u root -p ${MYSQLPASSWD} -d ${BACKUPDIR} -o -B ${DB_NAME}

 

3 对比测试

　　测试方式：分别采用mysqldump分表备份方式和mydumper的方式，mydumper默认4个线程，对单个或多个库进行备份，主要观察备份时间以及备份期间机器的CPU使用状况。

　　对单个数据库进行备份状况，默认采用4个线程同时备份：

 

	200M	4G	7G	30G
mysqldump	8s	2m58s	5m50s	13m13s
mydumper	4s	1m38s	2m56s	7m59s

　　对多个数据库连续备份，总共约8G大小的库

方式	时间
mysqldump	5m14s
mydumper	2m05s

　　在测试过程当中，观察机器的CPU使用状况，采用mysqldump的CPU使用约在98%左右，采用mydumper的状况下CPU使用约在200%－400%之间。因此对于消耗CPU的游戏来讲，采用mydumper无疑会增大CPU消耗负担，而且可能对游戏产生影响，因此并不太建议采用mydumper，而若是是专门的数据库而且CPU较为空闲的状况，能够采用，适当增多线程数，能够更快的完成备份。

　　另外在标配的单盘的机器上测试的时候发下，线程数设置为2的时候的时候，IO已经跑满了，相对于线程数为1的时候速度有显著提高，可是在IO跑满以后，设置线程数为四、八、10，线程数越大，CPU消耗会越大，可是对整个备份时间并无太大影响了，因此在cpu足够空闲的状况下，IO是影响mydumper性能的瓶颈所在，使用的时候根据实际IO状况合理设置线程数。