标签：MongoDB

第1章 常用命令简介:

mongoexport / mongoimport

mongodump  / mongorestore

1.1 备份工具区别在哪里:

?  mongoexport / mongoimport导入导出是JSON格式,而mongodump/mongorestore导入导出的是BSON格式

?  JSON可读性强但是体积较大,BSON则是二进制文件,体积小但是人类几乎没有可读性

?  在一些mongodb版本之间,BSON格式可能会随版本的不同而有所区别,所以不同版本之间用mongodump/mongorestore可能不会成功,具体要看版本之间的兼容性,当无法使用BSON进行跨版本的数据迁移的时候,使用JSON格式即mongoexport/mongoimport是一个可选项,跨版本的mongodump/mongorestore不推荐,

?  JSON虽然具有较好的跨版本通用性,但是只包里的数据部分,不保留索引,账户等其他基础信息

1.2 导出工具mongoexport :

MongoDB中的mongoimport工具可以把一个collection导出成json或csv格式的文件,可以通过惨呼指定导出的数据项,也可以根据指定的条件导出数据

命令参数:

1.3 导入工具mongoimport

MongoDB中的mongoimport工具可以把一个特定格式文件中农的内容导入到指定的collection中,该工具可以导入json格式数据,也可以导入csv格式数据

命令参数:

1.4 mongodump导出工具:

mongodump参数与mongoexport参数基本一致

1.5 mongorestore导入工具

mongorestore与mongoimport参数基本一致

第2章 mongoexport/mongoimport实践:

示例1-1 备份app库表vast集合:

mongoexport -h 10.0.0.18:28021 --authenticationDatabase admin -d app -c vast1 -o /mongodb/backup/vast.json

示例1-2 导出csv格式的备份:

mongoexport -h 10.0.0.18:28021 --authenticationDatabase admin -d app -c vast1 --type=csv -f id,name -o /mongodb/backup/vast.csv

示例1-3 将之前备份的数据导入

mongoimport -h 10.0.0.18:28024 --authenticationDatabase admin  -d app -c vast --drop /mongodb/backup/vast.json

示例1-4 将之前备份的csv格式数据导入

mongoimport -h 10.0.0.18:28024 --authenticationDatabase admin -d app -c vast1 --drop --type=csv --headerline  --file=/mongodb/backup/vast.csv

第3章 实践mysql数据迁移至MongoDB数据库:

3.1 将mysql数据库中mysql.user表导出:

?  mysql5.6中使用outfile需要开启相应参数:

vim /etc/my.cnf

secure-file-priv=/tmp

select user,password,host from mysql.user into outfile '/tmp/user.csv'

fields terminated by ',';

?  命令说明:

into outfile '/tmp/user.csv'    ------导出文件位置 

fields terminated by ','　　    ------字段间以,号分隔

还支持的命令,但是这里没有使用

optionally enclosed by '"'　    ------字段用"号括起

escaped by '"'   　　　　　   　------字段中使用的转义符为"

lines terminated by '\r\n';   　------行以\r\n结束

?  查看导出内容:

[root@db03 tmp]# cat user.csv

root,,localhost

root,,db03

root,,127.0.0.1

root,,::1

,,localhost

,,db03

repl,*23AE809DDACAF96AF0FD78ED04B6A265E05AA257,10.0.0.%

mha,*F4C9AC49A736981AE2739FC2F4A1FD92B4F07929,10.0.0.%

appuser,*23AE809DDACAF96AF0FD78ED04B6A265E05AA257,10.0.0.%

?  将数据上传至MongoDB服务器

scp -rp /tmp/user.csv root@10.0.0.18:/tmp

3.2 导入MongoDB数据库

mongoimport -h 10.0.0.18:28021 --authenticationDatabase admin -d app -c user -f name,pass,host --type=csv --file=/tmp/user.csv

?  查看数据:

sh1:PRIMARY> show tables

user

vast1

sh1:PRIMARY> db.user.find()

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521d8"), "name" : "root", "pass" : "", "host" : "localhost" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521d9"), "name" : "root", "pass" : "", "host" : "db03" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521da"), "name" : "root", "pass" : "", "host" : "127.0.0.1" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521db"), "name" : "root", "pass" : "", "host" : "::1" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521dc"), "name" : "", "pass" : "", "host" : "localhost" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521dd"), "name" : "", "pass" : "", "host" : "db03" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521de"), "name" : "repl", "pass" : "*23AE809DDACAF96AF0FD78ED04B6A265E05AA257", "host" : "10.0.0.%" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521df"), "name" : "mha", "pass" : "*F4C9AC49A736981AE2739FC2F4A1FD92B4F07929", "host" : "10.0.0.%" }

{ "_id" : ObjectId("5ad8290ce6bcf5822e0521e0"), "name" : "appuser", "pass" : "*23AE809DDACAF96AF0FD78ED04B6A265E05AA257", "host" : "10.0.0.%" }

数据迁移完成

第4章 mongodump实践

示例1-5 全库备份:

mongodump -h 10.0.0.18:28021 --authenticationDatabase admin -o /mongodb/backup

示例1-6 备份test库:

mongodump -h 10.0.0.18:28021 --authenticationDatabase admin  -d test -o /mongodb/backup

2018-04-19T13:50:31.901+0800    writing test.vast1 to

2018-04-19T13:50:31.903+0800    writing test.vast to

2018-04-19T13:50:31.908+0800    done dumping test.vast (0 documents)

2018-04-19T13:50:31.967+0800    done dumping test.vast1 (2000 documents)

[mongod@web04 backup]$ ll

drwxrwxr-x 2 mongod mongod    90 Apr 19 13:50 test

 [mongod@web04 backup]$ ll test/

-rw-rw-r-- 1 mongod mongod 152000 Apr 19 13:50 vast1.bson

-rw-rw-r-- 1 mongod mongod     82 Apr 19 13:50 vast1.metadata.json

-rw-rw-r-- 1 mongod mongod      0 Apr 19 13:50 vast.bson

-rw-rw-r-- 1 mongod mongod    137 Apr 19 13:50 vast.metadata.json

示例1-7 备份app库下user集合:

mongodump -h 10.0.0.18:28021 --authenticationDatabase admin  -d app -c user -o /mongodb/backup

2018-04-19T13:52:51.286+0800    writing app.user to

2018-04-19T13:52:51.289+0800    done dumping app.user (9 documents)

[mongod@web04 backup]$ ll

drwxrwxr-x 2 mongod mongod    47 Apr 19 13:52 app

 [mongod@web04 backup]$ ll app/

-rw-rw-r-- 1 mongod mongod 710 Apr 19 13:52 user.bson

-rw-rw-r-- 1 mongod mongod  80 Apr 19 13:52 user.metadata.json

示例1-8 压缩备份app库:

mongodump -h 10.0.0.18:28021 --authenticationDatabase admin  -d app -o /mongodb/backup --gzip

示例1-9 压缩备份app库下user集合:

mongodump -h 10.0.0.18:28021 --authenticationDatabase admin  -d app -c user -o /mongodb/backup --gzip

第5章 mongorestore实践

示例1-10 恢复之前备份的app库:  --drop表示恢复之前把原有的清除

mongorestore -h 10.0.0.18:28021 --authenticationDatabase admin -d app --drop  /mongodb/backup/app/

示例1-11 恢复app库下的user集合

mongorestore -h 10.0.0.18:28021 --authenticationDatabase admin -d app –c user --drop  /mongodb/backup/app/

第6章 oplog

6.1 什么是oplog?

MongoDB的replication是通过一个日志来存储写操作的,这个日志叫做oplog

在默认情况下,oplog分配的是5%的空闲磁盘空间,通常而言,这是一种合理的设置,可以通过mongodb—oplogsize来改变oplog的日志大小

oplog是capped collection，因为oplog的特点（不能太多把磁盘填满了，固定大小）需要，MongoDB才发明了capped collection（the oplog is actually the reason capped collections were invented）. 定值大小的集合，oplogSizeMB: 2048，oplog是具有幂等性，执行过后的不会反复执行。

6.2 oplog的位置:

?  oplog在local库 : local.oplog

?  master/slave架构下 : local.oplog.$main;

?  replica sets 架构下 : local.oplog.rs

6.2.1 mongodump参数中—oplog的作用:

该参数的主要作用是在导出的同时生成一个oplog.bson文件,存放你开始进行dump到dump结束之间所有的oplog

简单的说,在replica set中oplog是一个定容集合,他的默认大小是磁盘空间的5%,(可以通过oplogsize参数修改)位于local库中的db.oplog.rs

其中记录的是整个mongod实例一段时间内数据库的所有变更（插入/更新/删除）操作。当空间用完时新记录自动覆盖最老的记录

其覆盖的范围被称作oplog的时间窗口,需要注意的是,因为oplog是一个定容集合,所以时间窗口能覆盖的范围会因为你单位时间内的更新次数不同而变化

?  想要查看当前的oplog时间窗口预计值:

sh1:PRIMARY> rs.printReplicationInfo()

configured oplog size:   2048MB

log length start to end: 59363secs (16.49hrs)

oplog first event time:  Wed Apr 18 2018 22:46:09 GMT+0800 (CST)

oplog last event time:   Thu Apr 19 2018 15:15:32 GMT+0800 (CST)

now:                     Thu Apr 19 2018 17:50:17 GMT+0800 (CST)

oplog有一个非常重要的特性----幂等性,即对一个数据集合,使用oplog中记录的操作重放时,无论被重放多少次,其结果会是一样的

举例来说,如果oplog中记录的是一个插入操作,并不会因为你重放了两次,数据库中就得到两条相同的记录

6.3 oplog.bson作用:

?  与oplog相关的参数:

首先要明白数据之间互相有依赖性,比如两个集合中的数据互相具有依赖性,在一个任意的时间点,用mongodump进行备份时,如果两个集合的时间点不同,那么备份出来的数据也会不同,备份也就失去了意义

而使用了oplog功能,他会在dump数据的基础上,在重做一遍oplog中记录的所有操作,这时的数据就可以代表dump结束时的数据库状态,这个优点类似于mysql中binlog日志的使用

第7章 oplog企业应用

?  先插入多一些的数据

for(var i = 0; i < 100; i++) {     db.jiang.insert({a: i}); }

WriteResult({ "nInserted" : 1

?  在插入的过程中进行备份:

mongodump -h 10.0.0.18:28021 --oplog -o /mongodb/backup

注意:--oplog选项只对全库导出有效,所以不能指定-d选项,因为整个实例的变更操作都会几种在local库中的oplog.rs集合中

?  根据上面所述,从dump开始的时间西戎将记录所有的oplog到oplog.bson中,

[mongod@web04 backup]$ ll

drwxrwxr-x 2 mongod mongod   47 Apr 19 15:14 app

-rw-rw-r-- 1 mongod mongod 3663 Apr 19 15:14 oplog.bson

drwxrwxr-x 2 mongod mongod   49 Apr 19 15:14 test

?  查看oplog.bson中第一条和最后一条的内容:

[mongod@web04 backup]$ bsondump oplog.bson >/tmp/oplog.tmp

2018-04-19T15:22:28.617+0800    33 objects found

[mongod@web04 backup]$ head -1 /tmp/oplog.tmp

{"ts":{"$timestamp":{"t":1524122087,"i":166}},"t":{"$numberLong":"3"},"h":{"$numberLong":"2348342245314847788"},"v":2,"op":"i","ns":"test.jiang","o":{"_id":{"$oid":"5ad841e70c38e789b16b4f88"},"a":817.0}}

[mongod@web04 backup]$ tail -1 /tmp/oplog.tmp

{"ts":{"$timestamp":{"t":1524122088,"i":25}},"t":{"$numberLong":"3"},"h":{"$numberLong":"-1220572418158156634"},"v":2,"op":"i","ns":"test.jiang","o":{"_id":{"$oid":"5ad841e80c38e789b16b4fa8"},"a":849.0}}

最终dump出的数据既不是最开始的状态,也不是最后的状态,而是中间某个随机状态,这正是因为集合不断变化的造成的

?  使用mongorestore来恢复

mongodump -uroot -proot -h 10.0.0.18:28021 --oplog -o /mongodb/backup

7.1 获取oplog的方法:

?  在local库中导出

mongodump -h 10.0.0.18:28021 -d local -c oplog.rs -o /mongodb/backup

2018-04-19T15:34:45.145+0800    writing local.oplog.rs to

2018-04-19T15:34:45.530+0800    done dumping local.oplog.rs (22717 documents)

[mongod@web04 backup]$ cd local/

[mongod@web04 local]$ ll

-rw-rw-r-- 1 mongod mongod 2630171 Apr 19 15:34 oplog.rs.bson

-rw-rw-r-- 1 mongod mongod      83 Apr 19 15:34 oplog.rs.metadata.json

?  mongodump时加上—oplog参数,将会自动生成oplog,这种方式直接—pologReplay就可以恢复

?  说明:

既然dump出的数据配合oplog就可以把数据库恢复到某个状态，那是不是拥有一份从某个时间点开始备份的dump数据，再加上从dump开始之后的oplog，如果oplog足够长，是不是就可以把数据库恢复到其后的任意状态了？是的！

　　事实上replica set正是依赖oplog的重放机制在工作。当secondary第一次加入replica set时做的initial sync就相当于是在做mongodump，此后只需要不断地同步和重放oplog.rs中的数据，就达到了secondary与primary同步的目的。

　　既然oplog一直都在oplog.rs中存在，我们为什么还需要在mongodump时指定--oplog呢？需要的时候从oplog.rs中拿不就完了吗？答案是肯定的，你确实可以只dump数据，不需要oplog。

在需要的时候可以再从oplog.rs中取。但前提是oplog时间窗口必须能够覆盖dump的开始时间。

7.2 模拟生产环境

?  插入数据的同时备份

> for(i=0;i<30000;i++){ db.oplog.insert({"id":i,"name":"shenzheng","age":70,"date":new Date()}); }

另一个窗口进行备份:

mongodump -uroot -proot --port 27017  --oplog  -o /mongodb/backup/

?  备份完成后进行错误的操作

db.oplog.remove({});

?  备份oplog.rs文件

mongodump --port 27017 -d local -c oplog.rs -o  /mongodb/backup/oplog

?  恢复之前的备份的数据

?  截取oplog,找到发生误删除的时间点

?  复制oplog到备份目录

?  进行恢复,添加之前找到的误删除的点(limit)

第8章 分片集群的备份思路:

8.1 mongodb的备份准则:

只针对replica或master/slave,满足这些准则mongodb就可以进行point-in-time恢复操作

1.      任意两次备份的时间间隔(第一次备份开始到第二次备份结束)不能超过oplog时间窗口覆盖范围

2.      在上次数据备份的基础上,在oplog时间窗口没有滑出上次备份结束的时间点前进行完整的oplog备份,请充分考虑oplog备份需要的时间,权衡服务器空间情况决定oplog备份间隔

8.2 实际应用中的注意事项:

1.      考虑oplog时间窗口是个变化值,请关注oplog时间窗口的具体时间

2.      当靠近oplog时间窗口滑动出有效时间之前必须要有足够的时间dump出需要的oplog.rs,请预留出足够的时间,不要顶满时间窗口在备份

3.      当灾难发生时,第一件事情就是要停止数据库的写入操作,以往oplog滑出时间窗口,特别是像上述这样的remove({})操作,瞬间就会插入大量d记录从而导致oplog迅速滑出时间窗口

8.3 分片集群的备份注意事项:

1、备份什么？

　　（1）configserver

　　（2）每一个shard节点

2、备份需要注意什么？

　　（1）元数据和真实数据要有对等性（blancer迁移的问题，会造成config和shard备份不一致）

　　（2）不同部分备份结束时间点不一样，恢复出来的数据就是有问题的。

第9章 MongoDB监控

MongoDB集群监控方式:

第10章 mongodb集群性能优化方案:

10.1 1.5.1 优化方向

?  硬件（内存、SSD）

?  收缩数据

?  增加新的机器、新的副本集

?  集群分片键选择

?  chunk大小设置

?  预分片（预先分配存储空间）

10.2 1.5.2 存储引擎方面

　　WiredTiger是3.0以后的默认存储引擎，细粒度的并发控制和数据压缩提供了更高的性能和存储效率。3.0以前默认的MMAPv1也提高了性能。

　　在MongoDB复制集中可以组合多钟存储引擎，各个实例实现不同的应用需求。

10.3 1.5.3 其他优化建议

?  收缩数据

?  预分片

?  增加新的机器、新的副本集

?  集群分片键选择

?  chunk大小设置

第11章 Aliyun备份策略:

11.1 MongoDB云数据库备份恢复

11.2 备份策略:

?  从hidden节点备份

?  每天一次全量备份

?  持续拉取oplog增量备份

?  定期巡检备份有效性

?  恢复时克隆到新实例

11.3 全量备份方法:

11.4 逻辑备份流程-mongodump

11.4.1 特点:

?  全量遍历所有数据、

?  备份、恢复慢

?  对业务影响较大

?  无需备份索引、恢复时重建

?  通用性强

11.5 物理备份流程:

11.5.1 备份热点:

?  拷贝数据目录所有文件，效率高

?  备份、恢复快

?  对业务影响较小

?  跟数据库版本、配置强关联

11.6 逻辑备份VS物理备份:

MongoDB备份与恢复

标签：MongoDB

原文地址：http://blog.51cto.com/13520772/2112070