2015-09-24T00:06:11.929+0800 done dumping test.system.indexes (1 document)

2015-09-24T00:06:11.929+0800 writing test.foo to dump/test/foo.bson

2015-09-24T00:06:11.963+0800 done dumping test.foo (11162 documents)

?

可见我们导出了i=11162时的状态。等插入完成后，理论上我们的foo集合应该有100000条记录

?

> use test

switched to db test

> db.foo.count()

100000

现在假设我进行了一次误操作：

?

> db.foo.remove({})

WriteResult({ "nRemoved" : 100000 })

更惨的是我之后又往foo里面插入了一条数据

?

> db.foo.insert({a: 100001});

WriteResult({ "nInserted" : 1 })

现在怎样让时间倒流，回到灾难前的状态呢？由于在灾难前我们有过一次dump，因此现在只要在oplog时间窗口还能覆盖导出时间之前把oplog抢救出来就好了：

?

yaoxing ~ $ mongodump -h 127.0.0.1 -d local -c oplog.rs?

2015-09-24T00:09:41.040+0800 ? ?writing local.oplog.rs to dump/local/oplog.rs.bson

2015-09-24T00:09:41.525+0800 ? ?done dumping local.oplog.rs (200003 documents)

为什么会有200003条记录呢？请自行使用bsondump工具查看发生了什么事情。

?

从前面讲的可知，使用mongodump加oplog.bson（请注意文件位置）即可恢复数据库。这里的dump/local/oplog.rs.bson其实就是我们需要的oplog.bson。因此把它重命名后放到合适的位置，一个模拟出来的恢复环境就准备好了

?

yaoxing ~/dump $ ll

total 18464

-rw-r--r-- 1 yaoxing yaoxing 18900271 Sep 24 00:09 oplog.bson

drwxr-xr-x 2 yaoxing yaoxing ? ? 4096 Sep 24 00:06 test

但是这个oplog.bson可是包含了所有灾难操作的啊，如果全盘恢复回去，就等于是先让时光倒流，再看悲剧重演一遍。心都碎了……这时候你需要一个新朋友，就是上面提到的--oplogLimit。它与--oplogReplay一起使用时，可以限制重放到的时间点。那么重要的问题就是如何找到灾难发生的时间点了。仍然是bsondump。如果你对 Linux命令熟悉，可以在管道中直接操作。如果不行，那就先dump到文件中，再用文本编辑器打开慢慢找好了。我们需要找的内容是"op":"d"，它表示进行了一次删除操作。可以发现，oplog.bson中有100000次删除操作，实际上是一条一条把记录删除掉，这也是为什么remove({})操作会这么慢。如果对一个集合进行drop()就会快得多，它进行的操作请读者自己尝试。

?

yaoxing ~/dump $ bsondump oplog.bson | grep "\"op\":\"d\"" | head

{"b":true,"h":{"$numberLong":"5331406427126597755"},"ns":"test.foo","o":{"_id":{"$oid":"5602cdf1befd4a4bfb4d149b"}},"op":"d","ts":{"$timestamp":{"t":1443024507,"i":1}},"v":2}

...

此条记录中我们需要的是红色的$timestamp部分，它代表的发生这个操作的时间，也正是我们的--oplogLimit需要传入的时间，只是格式稍稍有变：

?

?

yaoxing ~ $ mongorestore -h 127.0.0.1 --oplogReplay --oplogLimit "1443024507:1" dump/

2015-09-24T00:34:09.533+0800 ? ?building a list of dbs and collections to restore from dump dir

2015-09-24T00:34:09.534+0800 ? ?reading metadata for test.foo from?

2015-09-24T00:34:09.534+0800 ? ?restoring test.foo from?

2015-09-24T00:34:09.659+0800 ? ?restoring indexes for collection test.foo from metadata

2015-09-24T00:34:09.659+0800 ? ?finished restoring test.foo (11162 documents)

2015-09-24T00:34:09.659+0800 ? ?replaying oplog

2015-09-24T00:34:11.548+0800 ? ?done

?

其中1443024507即是$timestamp中的"t"，1即是$timestamp中的"i"。这样配置后oplog将会重放到这个时间点以前，即正好避开了第一条删除语句及其后面的操作，数据库停留在灾难前状态。验证一下：

?

rs0:PRIMARY> db.foo.count()

100000

1.3 小结

?

结合上术知识，我们可以总结一些mongodb的备份准则（只针对replica或master/slave），满足这些准则，MongoDB就可以进行point-in-time恢复操作：

?

任意两次数据备份的时间间隔（第一次备份开始到第二次备份结束）不能超过oplog时间窗口覆盖范围。

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

实际应用中的注意事项：

?

考虑到oplog时间窗口是个变化值，请关注oplog时间窗口的具体时间。

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

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

2. 外置方法

1. MMS/Cloud Manager

?