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跑满之后，设置线程数为4、8、10，线程数越大，CPU消耗会越大，但是对整个备份时间并没有太大影响了，所以在cpu足够空闲的情况下，IO是影响mydumper性能的瓶颈所在，使用的时候根据实际IO情况合理设置线程数。
