1 环境描述

1.1 硬件环境

　　服务器类型：华为RH5885

　　IP: 10.148.128.100

　　内存: 64G

　　物理CPU个数：4

　　CPU核数：8

　　逻辑CPU个数：64

　　Intel(R) Xeon(R) CPU E7-4820 v2 @ 2.00GHz

1.2 Mysql版本

　　数据库备份还原——mysqlbackup与mysqldump对比测试-LMLPHP

1.3 数据环境

　　生产按照130MW满规格进行测试。所测试备份的最大数据量为381G。

　　由于监控数据量远小于生产，故重点对生产的备份还原进行了测试。

　　监控只测试了数据量较小的情况，可参考生产的备份还原情况对其进行粗略估计。

2 采用的数据库备份方法

2.1 Mysqlbackup

　　Mysqlbackup是物理备份的方式。对innodb的表空间进行物理复制，但是，它是记录LSN点的。在备份过程中，新增加的输入直接写入备份文件的ibbackup_logfile中。同时记录最后的LSN点。还原的时候，检测对比ibbackup_logfile文件里面与表空间里面的差值，使ibbackup_logfile里面的数据进入事务日志或表空间。

2.1.1 压缩备份

备份:

time /opt/mysql/meb-3.11/bin/mysqlbackup --compress --backup-dir=/srv/mytest --socket=/opt/mysql/data/mysql.sock --datadir=/opt/mysql/data -usystem -pHwsystem@com --include-tables="eSCS" backup

说明：--compress 压缩备份

还原:

1．检查事务日志，并解压

time /opt/mysql/meb-3.11/bin/mysqlbackup --uncompress --backup-dir=/srv/mytest apply-log

【说明】：Apply-log之前，数据文件是不一致的，因为它们在不同时间点被备份。因此，apply-log会使所有数据文件的步调达成一致。通过innodb 的crash recovery把已经提交的事务写入数据文件，把没有提交的事务进行回滚。apply-log没有强制在线上或者备份库上运行。

2. 还原物理文件

time /opt/mysql/meb-3.11/bin/mysqlbackup --defaults-file=/etc/my.cnf --backup-dir=/srv/mytest --datadir=/opt/mysql/data copy-back

【注意】：压缩备份只能应用于全备，不能对增量备份进行压缩；
压缩备份不能应用与已经是压缩格式（Barracuda file format）的innodb 表。

2.1.2 非压缩备份

备份

time /opt/mysql/meb-3.11/bin/mysqlbackup --backup-dir=/srv/mytest --socket=/opt/mysql/data/mysql.sock --datadir=/opt/mysql/data -usystem -pHwsystem@com --include-tables="eSCS" backup

说明：--compress 压缩备份

还原

time /opt/mysql/meb-3.11/bin/mysqlbackup --backup-dir=/srv/mytest apply-log

time /opt/mysql/meb-3.11/bin/mysqlbackup --defaults-file=/etc/my.cnf --backup-dir=/srv/mytest --datadir=/opt/mysql/data copy-back

2.2 Mysqldump

Mysqldump是mysql自带工具。备份出来的文件是一个可以直接倒入的sql脚本。该sql文件中实际上包含了多个CREATE 和INSERT语句，使用这些语句可以重新创建表和插入数据。

2.2.1 压缩备份

备份

time mysqldump -usystem -pHwsystem@com --databases platform_eSCS910 eSCS | gzip > /opt/mybackupfile.sql.gz ;

还原

time gunzip < /opt/mybackupfile.sql.gz | mysql -usystem -pHwsystem@com

2.2.2 非压缩备份

备份

time mysqldump -usystem -pHwsystem@com --databases platform_eSCS910 eSCS > /opt/mybackupfile.sql

还原

time mysql -usystem -pHwsystem@com < /opt/mybackupfile.sql

3 测试结果

3.1 910数据库备份还原测试

备份方法	原始文件大小	备份文件大小	备份耗时	还原耗时
压缩	非压缩	压缩	非压缩	压缩	非压缩
Mysqldump	13M ./eSCS 1.8M ./mysql 635K ./performance_schema 2.8M ./platform_eSCS910 191M /opt/mysql/data	112K	881K	0.34s	0.32s	2.47s	2.47s
Mysqlbackup	2.8M (189M)	92M (189M)	4.11s	5.10s	6.00s (2.94+ 3.06）	4.13s (1.039+ 3.09)
Mysqldump	419M ./eSCS 25M ./mysql 635K ./performance_schema 2.8M ./platform_eSCS910 619M /opt/mysql/data	2M	25M	1m18.723s	1m19.123s	1m9.389s	1m9.736s
Mysqlbackup	58M (596M)	499M (596M)	45.969s	45.92s	1m11.64s (22.600s +49.038s)	47.13s (1.955s +45.173s)

注1：执行检查事务日志(apply-log)后，备份文件目录大小为：189M

注2：backup还原耗时为：apply-log + copy-back的总和。

3.2 710数据库备份还原测试

备份方法	原始文件大小	备份文件大小	备份耗时	还原耗时
压缩	非压缩	压缩	非压缩	压缩	非压缩
Mysqldump	5.8G ./ePMS 419M ./eSCS 14M ./mysql 635K ./performance_schema 2.9M ./platform_ePMS710 2.8M ./platform_eSCS910 6.9G .	90M	2.7G	1m11.39s	54.59s	8m7.24s	8m3.01s
Mysqlbackup	569M (6.4G)	6.3G (6.4G)	41.56s	41.59s	1m15.53s (28.694s+ 46.832s)	47.38s (1.189s +46.189s）
Mysqldump	27G ./ePMS 28G /opt/mysql/data （此数据环境为43G Mysqldump恢复之后的环境）	---	---	---	---	---	---
Mysqlbackup	3.0G （28G） (压缩率89.20%)	27G （28G）	3m18.77s	3m4.86s	6m30.01s (2m42.407s+ 3m47.713s）	3m47.99S (1.163s+ 3m46.839s)
Mysqldump	43G ./ePMS 44G /opt/mysql/data	770M	21G	9m26.54s	7m12.97s	64m44.67s	62m48.03s
Mysqlbackup	---	---	---	---	---	---
Mysqldump	381G ./ePMS 13M ./eSCS 11M ./mysql 635K ./performance_schema 2.9M ./platform_ePMS710 2.8M ./platform_eSCS910 381G /opt/mysql/data	3.4G 注	203G	4h44m31.66s *备注2**	4h45m10.09s	11h45m20.86s 注：恢复完成后数据仅223G！(磁盘空间足够)	11h35m33.76s 注：恢复完成后数据仅238G！(磁盘空间足够) *备注1**
Mysqlbackup	24G (压缩率93.90%)	381G	46m19.47s	40m46.95s	解压到223G(耗时16m38.9s)，磁盘满，还原失败。	52m8.423s
Mysqldump	238G ./ePMS 238G /opt/mysql/data （此数据环境为381G Mysqldump恢复之后的环境）	3.4G	---	1h41m0.22s	---	---	---
Mysqlbackup	17G	---	30m36.27s	---	---	---

备注1*： mysqldunp方式还原后，文件占用大小与备份前数据大小不一致。对比备份前后数据库表记录条数：发现是一致的！

具体而言，文件大小减少的是某些数据文件(*.ibd)，由于还原时对数据文件进行了重新整理而节约了空间。

图：测试dump还原后数据量变小

备注2* ：此处Mysqldump耗时可能会更高一些。这个第二次测试的数据，第一次测试耗时128m41s才备份完1.1G。觉得遥遥无期故手动中断。按照备份完3.4G计算，备份大概需要6-7小时，高于表中所示数据。

数据库备份还原——mysqlbackup与mysqldump对比测试-LMLPHP

图：dump备份耗时可能会更久，估计与系统运行状态有关

4 总结与分析

4.1 时间消耗

共部署情况，710/910备份及还原耗时情况，只与本网元数据库数据量有关，基本不受共部署另一网元影响。
数据还原的耗时大于备份的耗时。
Mysqlbackup耗时情况：

　　数据库备份还原——mysqlbackup与mysqldump对比测试-LMLPHP

图1. Mysqlbackup耗时情况

1） Mysqlbackup物理备份方式主要是进行文件的拷贝。其备份耗时与数据量大小呈较稳定的线性关系。在该测试环境下，基本满足：y=7.3x。

2）压缩耗时差异：

Mysqlbackup方法，压缩与否的备份耗时基本相同。

但还原时，压缩情况要比非压缩耗时长，约为非压缩情况的1-2倍(执行copyback的时间与备份时间相当，时间多在执行apply-log解压上)。还原的时间统计图暂未列出。

Mysqldump耗时情况：

　　数据库备份还原——mysqlbackup与mysqldump对比测试-LMLPHP

　　图2. Mysqldump耗时情况 及Mysqlbackup对比

1）在数据量较小时（10-100M数据量，如初始安装状态），Mysqldump耗时较少，低于Mysqlbackup方法。

2）粗略估计：400M数据情况下，Mysqldump、Mysqlbackup耗时相当。

3）当数据量增加时（1G数据量以上），Mysqldump耗时增长较快。且随着数据量的增加，耗时远远大于Mysqlbackup方法。

可参考以上测试结果，估算大概耗时情况。

4）对于Mysqldump方法，压缩与否的耗时基本相同(包括备份、还原)。

5）Mysqldump备份耗时与原数据存储的紧凑程度有较大的关系。

【其他说明】：以上测试结果都在第1.1节说明的环境下进行。若在E9000虚拟机上测试(分配20G内存，4 CPU)，根据实际耗时：备份耗时比此环境下测试结果高1-2倍，还原耗时比此环境高3-7倍。(仅测试了mysqldump方式，且不够充分，这里是粗略总结。)

4.2 空间占用

压缩率

　　　　Mysqldump ：压缩率约为：96.5%。

　　　　Mysqlbackup：压缩率也在90%以上。二者压缩效率都很可观！

　　　　之前说了压缩与否耗时基本相当。故采用压缩的方式进行备份和还原是比较划算的。

Mysqldump与Mysqlbackup比较：

　　　　压缩情况下Mysqldump与Mysqlbackup备份文件占用空间都不大。其次，Mysqldump逻辑备份的方式，其备份文件比Mysqlbackup的小。Mysqldump还原操作后，数据文件占用空间与原数据文件相比要小。

　　　　Mysqlbackup还原操作时，检查事务文件并解压，解压完成后空间占用与原始文件(/opt/mysql/data/下)大小一致。

4.3 对系统性能影响

　　　　1. 数据量较大时，Mysqldump方法会消耗大量内存和CPU资源，也直接影响了自身的备份性能，导致在数据量大时备份速度更慢。

　　　　数据库备份还原——mysqlbackup与mysqldump对比测试-LMLPHP

　　　　2. Mysqlbackup方法系统资源占用较少，基本不造成影响。这也从另一方面反映了其耗时呈线性状态的原因。

　　　　3. Mysqlbackup还原时，请首先停掉数据库！否则，还原结束后，重启mysql服务会有异常。

　　　　4. Mysqlbackup还原时，第一步时检查事务文件并解压。请注意检查磁盘空间，确保备份所在目录空间足够！否则解压失败后无法继续进行还原操作：

4.4 备份还原注意事项

我们采用的存储引擎是innodb，默认是共享表空间，即数据库所有表数据、索引文件都放在/opt/mysql/data/ibdata1文件。共部署情况下Mysqlbackup还原可能存在问题，执行还原成功后数据库可能无法正常使用。

===================================================

附录其他数据备份还原方式

　　其实，在mysqldump使用手册上已经说明了，在数据量大的时候，并不适合采用mysqldump方式，其推荐采用的是物理备份的方式。然而Mysqlbackup物理备份的方式对共部署环境并不太适用(或者我们还不是很会用)。其他InnoDB 表备份/恢复策略小结：

　　1. 使用商业的在线热备份工具 Hotbackup

　　　　Hotbackup可以在InnoDB数据库运行之时备份你的InnoDB数据库，并且它不设置任何锁定或干扰你正常的数据库处理。缺点：付费。

　　2. Xtrabackup

　　　　Xtrabackup是一个对InnoDB做数据备份的工具，支持在线热备份（备份时不影响数据读写），据说是商业备份工具InnoDB Hotbackup较好的替代品。

　　3. 使用sql 语句备份

　　　　 select into 热备份单个/多个表。与mysqldump很相似，同样是把数据库备份到一个指定的文件中。常用于创建表的备份复件或者用于对记录进行存档。

　　4. 拷贝文件

　　　　直接备份数据文件较为直接、快速、方便。缺点是基本上不能实现增量备份。
　　　　为了保证数据的一致性，需要在拷贝文件前，执行以下 SQL 语句： FLUSH TABLES WITH READ LOCK;把内存中的数据都刷新到磁盘中，同时锁定数据表，以保证拷贝过程中不会有新的数据写入。
　　　　注意，对于 Innodb 类型表来说，还需要备份其日志文件，即 ib_logfile* 文件。总的来说，直接拷贝的方式可靠性低。

备份

数据库备份还原——mysqlbackup与mysqldump对比测试

1 环境描述

1.1 硬件环境

1.2 Mysql版本

1.3 数据环境

2 采用的数据库备份方法

2.1 Mysqlbackup

2.1.1 压缩备份

2.1.2 非压缩备份

2.2 Mysqldump

2.2.1 压缩备份

2.2.2 非压缩备份

3 测试结果

3.1 910数据库备份还原测试

3.2 710数据库备份还原测试

4 总结与分析

4.1 时间消耗

4.2 空间占用

4.3 对系统性能影响

4.4 备份还原注意事项

附录 其他数据备份还原方式

附录其他数据备份还原方式