MongoDB 如何实现备份压缩

时间 2019-12-10

原文原文链接

背景及原理

数据库的备份是灾难恢复的最后一道屏障，无论什么类型的数据库都须要设置数据库备份，MongoDB也不例外。MongoDB 3.0 后，数据库能够采用Wiredtiger存储引擎后（3.2 版本默认），在此环境下经过mongodump 备份后，产生的备份文件要远大于数据存储文件的大小。此外，通常MongoDB存储的数据量比较大，备份文件也比较大，占用了不少磁盘空间。因此，研究如何实现MongoDB备份压缩颇有必要。mongodb

上图是执行命令 db.stats() 查看某数据库的信息。数据库

备份文件的大小通常为dataSize的大小，因此咱们但愿压缩备份，能够达到storageSize 或者更小。服务器

一般的备份思路是先备份，后对备份文件进行压缩。以前，咱们采用的就是这种方式，例如主要压缩命令以下性能

tar -cf - ${targetpath}/${nowtime} | pigz -p 10 > ${targetpath}/${nowtime}.tgz测试

（命令解释： targetpath}/${nowtime 为待压缩的备份文件；pigz 是Linux压缩神器，可并行压缩；-p是指定cpu的核数。）spa

可是这种方式，生成备份文件的过程当中仍是容易造成磁盘性能压力和空间压力。下图为咱们某台Server 采用先备份后压缩方式，造成的磁盘可用空间变化。rest

真正但愿的是在备份的同时进行压缩，这样可用空间就比较平稳了。在MongoDB 3.2 中引入了一种压缩式备份【此mongodb版本必须不低于3.2】。可使用gzip进行压缩。这是经过在mongodump和mongorestore中引入一个新的指令行选项“- -gzip”实现的。blog

压缩可用于目录以及归档模型下建立的备份，压缩还能够减小磁盘空间使用。ip

测试

测试环境：ci

测试服务器	测试数据库	端口	文件路径
172.X.X.245	实例全备	17219	/data/mongodb_back
172.X.X.246	QQ_DingDing	17218	/data/mongodb_back/QQ_DingDing

Step 1 压缩式备份的命令：

./mongodump --host 172.X.X.245 --port 17219 -u 用户名 -p "密码" --gzip --authenticationDatabase "admin" --out /data/mongodb_back

备份后文件的大小，97M

这时候，查看备份文件的格式都变成了.gz的格式

Step 2 将备份文件copy至远程机器上，进行还原：

如下命令是将在172.X.X.246，要求是将文件从X.245 copy至本地

scp -r root@172.X.X.245:/data/mongodb_back/QQ_DingDing

step 3 执行还原的命令

执行的命令

./mongorestore --host 172.X.X.246 --port 17218 -d QQ_DingDing -u 用户名 -p "密码" --gzip --authenticationDatabase "admin" /data/mongodb_back/QQ_DingDing

还原后登陆MongoDB，执行show dbs，查看此时数据大小为500M。

补充说明

(1) 若是不采用压缩式的备份，备份后的文件会是多大呢？备份命令：

./mongodump --host 172.X.X.245 --port 17219 -u 用户名 -p "密码" --authenticationDatabase "admin" --out /data/mongodb_back2

查看此种方法备份后的文件大小--1.5G。

以此QQ_DingDing数据库为例，其压缩率为（文件压缩后的大小与压缩前的大小之比）：97M/1.5G=97/1536=6.3%

(2) 这种压缩备份的方式的会不会带来一些弊端：例如备份时间增加？（恢复时间增长？，请自测一下试试，嘻嘻 @@@）

以某归档备份库所在实例为例（storageSize 150G，dataSize 600G ）

采用先备份后压缩的方式耗时1小时55分钟

采用压缩式备份（指定--gzip参数）的方式耗时 2小时33分钟

产生的备份文件大小基本相等，压缩式备份方式产生的备份文件略小

因此压缩式备份会致使备份时间增加。

但从空间使用的角度来说，咱们仍然建议你们使用压缩式备份，其压缩比很是高（测试案例的压缩比6.3%）。

本文版权归做者全部，未经做者赞成不得转载,谢谢配合！！！