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版本

  

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)

注1

92M

(189M)注1

4.11s

5.10s

6.00s

(2.94+

3.06)注2

4.13s

(1.039+

3.09)注2

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)注1

6.3G

(6.4G)   

注1

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小时,高于表中所示数据。

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

4     总结与分析

4.1      时间消耗

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

           

         图1.  Mysqlbackup耗时情况

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

2) 压缩耗时差异:

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

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

  1. Mysqldump耗时情况:

  

  图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      空间占用

  1. 压缩率

    Mysqldump :压缩率约为:96.5%。

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

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

  1. Mysqldump与Mysqlbackup比较:

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

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

4.3      对系统性能影响

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

    

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

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

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

4.4      备份还原注意事项

  1. 我们采用的存储引擎是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* 文件。总的来说,直接拷贝的方式可靠性低。

  5. Navicat工具备份

    

    优缺点:使用方便,但是备份和还原时间都比较长。

数据库备份还原——mysqlbackup与mysqldump对比测试的更多相关文章

  1. MySQL数据库备份还原(基于binlog的增量备份)

    MySQL数据库备份还原(基于binlog的增量备份) 一.简介 1.增量备份      增量备份 是指在一次全备份或上一次增量备份后,以后每次的备份只需备份与前一次相比增加或者被修改的文件.这就意味 ...

  2. 第二百九十节,MySQL数据库-MySQL命令行导出导入数据库,数据库备份还原

    MySQL命令行导出导入数据库,数据库备份还原 MySQL命令行导出数据库:1,进入MySQL目录下的bin文件夹:cd MySQL中到bin文件夹的目录如我输入的命令行:cd C:\Program ...

  3. MSSQL2008数据库备份还原和数据恢复

    原文:MSSQL2008数据库备份还原和数据恢复   序言 一直想写一篇关于数据库备份与恢复的文章,但基于能力的有限对数据库认知的有限怕不足以准确的表达,最后思考很久还是决定把自己的一些理解写出来供大 ...

  4. SQL server数据库备份还原问题备忘(亲测有效)

    问题一:SQL server数据库备份还原方法 http://www.cnblogs.com/zgqys1980/archive/2012/07/04/2576382.html 问题二:无法执行 BA ...

  5. 查询清除SQL Server数据库备份还原历史记录

    曾经遇到过一个用户MSDB数据库非常大,让我帮忙查查是什么原因.使用sp_spaceused找出了所有表的数据大小,发现问题是SQL Server备份和还原历史表数据太大.用户经常会做日志备份,但是从 ...

  6. [整理] C#调用SQLDMO.DLL时间数据库备份 / 还原。 (香神无涯) // C#实现SQLSERVER2000数据库备份还原的两种方法 (带进度条)

    /// <summary>/// 通过调用MSSQL的SQLDMO.DLL文件来实现备份数据库/// 1.首先在在项目中引用SQLDMO.DLL文件./// 2.在引用中的SQLDMO.D ...

  7. C#中数据库备份还原 精简

    C#中数据库备份还原 使用前要导入SQLDMO.dll(在com组件中导入Microsoft SQLDMO Object Library即可) ///     /// DbOper类,主要应用SQLD ...

  8. Oracle数据库备份还原笔记

    Oracle数据库备份还原笔记 通过查阅资料知道Oracle备份还原的方式有三种.分别的是导出/导入.热备份和冷备份.导出/导入是一种逻辑备份.而热备份和冷备份是物理备份.[参考资料(https:// ...

  9. SQL Server数据库备份&还原

    一.备份 1.登录数据库 2.找到要还原的数据库 右键-任务-备份-添加(路径只写一个,刚开始二个总是报错)-确定 二.还原数据库 这个之间报错了二次 1.报错1:备份集中的数据库与现有数据库“XXX ...

随机推荐

  1. Fedora25安装mariadb并设置权限

    MariaDB版本10.1.21 Fedora版本25 1.Change root user sudo -i 2. dnf install -y mysql dnf install -y mariad ...

  2. List<Map>中根据map的同一指标项数据——去重代码

    先看网络上,博客经常出现的错误代码: for(ABatchAddCheckVO aBatchAddCheckVO : addList){ dto.put("aac001",aBat ...

  3. PostGIS 通过SQL语句实现空间分析【入门级】

    PostGIS是对象关系型数据库系统PostgreSQL的一个扩展,PostGIS提供如下空间信息服务功能:空间对象.空间索引.空间操作函数和空间操作符.同时,PostGIS遵循OpenGIS的规范. ...

  4. Leetcode208. Implement Trie (Prefix Tree)实现Trie(前缀树)

    实现一个 Trie (前缀树),包含 insert, search, 和 startsWith 这三个操作. 示例: Trie trie = new Trie(); trie.insert(" ...

  5. C++ 系列:随机数

    C++中没有自带的random函数,要实现随机数的生成就需要使用rand()和srand().不过,由于rand()的内部实现是用线性同余法做的,所以生成的并不是真正的随机数,而是在一定范围内可看为随 ...

  6. ES5给object扩展的一些静态方法

    1. Object.create(prototype[, descriptors]) : 创建一个新的对象 1). 以指定对象为原型创建新的对象 2). 指定新的属性, 并对属性进行描述 value ...

  7. Java 多线程 - ThreadLocal

    ref: https://www.cnblogs.com/chengxiao/p/6152824.html

  8. Orika JavaBean映射工具探秘

    Orika是一个简单.快速的JavaBean拷贝框架,Orika使用字节代码生成来创建具有最小开销的快速映射器. 关于: 作为开发人员,我们必须为业务问题提供解决方案,我们希望利用我们的时间来做真正重 ...

  9. Could not open file ..\obj\sys.o: No such file or directory解决办法

    一.你的keil的安装路径以及系统用户名是否带中文字符以及一些特殊字符.二.环境变量的值存在中文或者特殊字符了,解决方法如下: 1.在C盘建立一个新的文件夹,命名为英文,如qcl2.右击"此 ...

  10. 运用shtml类型文件,实现项目页面的分割。

    学过动态网页,如asp.php的人知道如何去引用网站头部.底部文件包含.例如在php中有一个方法:include();这个方法能在当前文档中引入外部文件,从而方便网站的开发和维护,然而html静态文件 ...