幽灵幻影卡尔萨斯,生产洗发水,泰拉斯黑角
数据库的备份是灾难恢复的最后一道屏障，不管什么类型的数据库都需要设置数据库备份，mongodb也不例外。mongodb 3.0 后 ，数据库可以采用wiredtiger存储引擎后（3.2 版本默认），在此环境下通过mongodump 备份后，产生的备份文件要远大于数据存储文件的大小。此外，一般mongodb存储的数据量比较大，备份文件也比较大，占用了很多磁盘空间。所以，研究如何实现mongodb备份压缩很有必要。
上图是执行命令 db.stats() 查看某数据库的信息。
备份文件的大小一般为datasize的大小，所以我们希望压缩备份，可以达到storagesize 或者更小。
一般的备份思路是先备份，后对备份文件进行压缩。之前，我们采用的就是这种方式，例如主要压缩命令如下
tar -cf - ${targetpath}/${nowtime} | pigz -p 10 > ${targetpath}/${nowtime}.tgz
（命令解释： targetpath}/${nowtime 为待压缩的备份文件；pigz 是linux压缩神器，可并行压缩；-p是指定cpu的核数。）
但是这种方式，生成备份文件的过程中还是容易形成磁盘性能压力和空间压力。下图为我们某台server 采用先备份后压缩方式，形成的磁盘可用空间变化。
真正希望的是在备份的同时进行压缩，这样可用空间就比较平稳了。在mongodb 3.2 中 引入了一种压缩式备份【此mongodb版本必须不低于3.2】。可以使用gzip进行压缩。这是通过在mongodump和mongorestore中引入一个新的指令行选项“- -gzip”实现的。
压缩可用于目录以及归档模型下创建的备份，压缩还可以减少磁盘空间使用。
测试环境：
|
测试服务器 |
测试数据库 |
端口 |
文件路径 |
|
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分钟
产生的备份文件大小基本相等，压缩式备份方式产生的备份文件略小
所以 压缩式备份会导致备份时间增长。
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
理解Redis持久化，RDB持久化和AOF持久化的不同处理方式
Redis 两类持久化方式，快照和全量追加日志的不同处理方式
我要评论
网友评论