您的位置:首页 > 数据库 > 其它 > 正文

mongodb备份和还原

更多 时间:2013-9-15 类别:数据库 浏览量:6058

mongodb备份和还原

mongodb备份和还原

数据的备份无论什么时候都是必须的,尤其是重要数据。

MongoDB也提供了备份和还原的功能,分别是MongoDB下载目录下的mongdump.exe和mongorestore.exe文件。

这两个命令将mongodb的数据dump为BSON格式,需要的时候可以恢复。这种方式作为小的数据库还适用。但如果是sharding或者几百G数据以上的话,就几乎不可用了。因为BSON极其占用空间。
 

 

一、备份和还原的命令语法

 

备份:


mongodump -h dbhost -d mailaccess -c Mail -q ‘{user:”zhaoxy1@szdep.com”}’ -o /data/dump


备份mailaccess database的Mail collection到/data/dump目录


-h:MongDB所在服务器地址,例如:127.0.0.1,当然也可以指定端口号:127.0.0.1:27017

-d:备份哪个数据库
-c:备份哪个collection(可选,不传默认为整个database)
-q:指定备份collection的条件(与-c参数一起使用)

-o:备份的数据存放位置,例如:c:\data\dump,当然该目录需要提前建立,在备份完成后,系统自动在dump目录下建立一个test目录,这个目录里面存放该数据库实例的备份数据。

 

还原:

mongorestore -h dbhost -d dbname --directoryperdb dbdirectory –drop /data/dump/mailaccess
 

-h:MongoDB所在服务器地址

-d:需要恢复的数据库实例,例如:test,当然这个名称也可以和备份时候的不一样,比如test2

--directoryperdb:备份数据所在位置,例如:c:\data\dump\test,这里为什么要多加一个test,而不是备份时候的dump,读者自己查看提示吧!

--drop:恢复的时候,先删除当前数据,然后恢复备份的数据。就是说,恢复后,备份后添加修改的数据都会被删除,慎用哦!

 

二、Master-Slave 方式备份

主从复制模式:即一台主写入服务器,多台从备份服务器。从服务器可以实现备份,和读扩展,分担主服务器读密集时压力,充当查询服务器。但是主服务器故障时,我们只能手动去切换备份服务器接替主服务器工作。这种灵活的方式,使扩展多如备份或查询服务器相对比较容易,当然查询服务器也不是无限扩展的,因为这些从服务器定期在轮询读取主服务器的更新,当从服务器过多时反而会对主服务器造成过载。

我们以之前创建的端口为27017做为主服务器,再创建个端口为27018从服务器

重新启动27017为主服务器 --master 主服务器

       bin>mongod  --dbpath "C:\Program Files\mongodb\data\dbs\master" --master

创建27018为从服务器  --slave 从服务器  --source 指定主服务器

       bin>mongod --port 27018 --dbpath "C:\Program Files\mongodb\data\dbs\slave27018"   --slave --source localhost:27017

主服务器可以通过自己local库的slave集合查看从服务器列表

从服务器可以通过自己local库的source集合查看主服务器信息或维护多个主服务器。 (一个slave服务器可以服务多个master服务器)

或者我们可以通过http console查看状态。

 

三、Replica Sets 方式备份

副本集模式:具有Master-Slave模式所有特点,但是副本集没有固定的主服务器,当初始化的时候会通过多个服务器投票选举出一个主服务器。当主服务器故障时会再次通过投票选举出新的主服务器,而原先的主服务器恢复后则转为从服务器。Replica Sets的在故障发生时自动切换的机制可以极时保证写入操作。

这里在简单的介绍一下Master Slave/ Replica Sets 备份机制,这两种模式都是基于主服务器的oplog 来实现所有从服务器的同步。

oplog记录了增删改操作的记录信息(不包含查询的操作),但是oplog有大小限制,当超过指定大小,oplog会清空之前的记录,重新开始记录。

Master Slave方式主服备器会产生 oplog.$main 的日志集合。

Replica Sets 方式 所有服务器都会产生oplog.rs 日志集合。

两种机制下,所有从服务器都会去轮询主服务器oplog日志,若主服务器的日志较新,就会同步这些新的操作记录。但是这里有个很重要的问题,从服务器由于网络阻塞,死机等原因无法极时同步主服务器oplog记录:一种情况 主服务器oplog不断刷新,这样从服务器永远无法追上主服务器。另外一种情况,刚好主服务器oplog超出大小,清空了之前的oplog,这样从服务器就与主服务器数据就可能会不一致了,这第二种情况,我是推断的,没有证实。

另外要说明一下Replica Sets 备份的缺点,当主服务器发生故障时,一台从服务器被投票选为了主服务器,但是这台从服务的oplog 如果晚于之前的主服务器oplog的话,那之前的主服务器恢复后,会回滚自己的oplog操作和新的主服务器oplog保持一致。由于这个过程是自动切换的,所以在无形之中就导致了部分数据丢失。