?

后面再做介绍。先来看一个例子：

?

首先我们模拟一个不断有插入操作的集合foo，

?

use test

for(var i = 0; i < 100000; i++) {

? ? db.foo.insert({a: i});

}

然后在插入过程中模拟一次mongodump并指定--oplog。

?

mongodump -h 127.0.0.1 --oplog

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

?

根据上面所说，从dump开始的时间 系统将记录所有的oplog到oplog.bson中，所以我们得到这些文件：

?

yaoxing ~ $ ll dump/

total 440

-rw-r--r-- 1 yaoxing yaoxing 442470 Sep 14 17:21 oplog.bson

drwxr-xr-x 2 yaoxing yaoxing ? 4096 Sep 14 17:21 test

其中test是我们刚才使用的数据库，oplog.bson是导出期间进行的所有操作。如果对oplog.bson中的内容好奇，可以用bsondump工具来查看其中的内容，例如：

?

{"h":{"$numberLong":"2279811375157953332"},"ns":"test.foo","o":{"_id":{"$oid":"55f834ae6b530b5854f9d6ee"},"a":7784.0},"op":"i","ts":{"$timestamp":{"t":1442329774,"i":3248}},"v":2}

从oplog.bson中我们挑选第一条和最后一条内容出来观察

?

{"h":{"$numberLong":"2279811375157953332"},"ns":"test.foo","o":{"_id":{"$oid":"55f834ae6b530b5854f9d6ee"},"a":7784.0},"op":"i","ts":{"$timestamp":{"t":1442329774,"i":3248}},"v":2}

...

{"h":{"$numberLong":"-1177358680665374097"},"ns":"test.foo","o":{"_id":{"$oid":"55f834b26b530b5854f9fa5e"},"a":16856.0},"op":"i","ts":{"$timestamp":{"t":1442329778,"i":1361}},"v":2}

红字部分可以看出，从开始进行mongodump时，循环进行到i=7784，而到整个操作结束时，循环进行到i=16856。再看一下test/foo.bson中数据的最后一条

?

{"_id":{"$oid":"55f834ae6b530b5854f9d73d"},"a":7863.0}

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

?

那么使用mongorestore来恢复：

?

?

yaoxing ~ $ mongorestore -h 127.0.0.1 --oplogReplay dump

2015-09-19T01:22:20.095+0800 ? ?building a list of dbs and collections to restore from dump dir

2015-09-19T01:22:20.095+0800 ? ?reading metadata for test.foo from?

2015-09-19T01:22:20.096+0800 ? ?restoring test.foo from?

2015-09-19T01:22:20.248+0800 ? ?restoring indexes for collection test.foo from metadata

2015-09-19T01:22:20.248+0800 ? ?finished restoring test.foo (7864 documents)

2015-09-19T01:22:20.248+0800 ? ?replaying oplog

2015-09-19T01:22:20.463+0800 ? ?done

?

注意红字的两句，第一句表示test.foo集合中恢复了7864个文档；第二句表示重放了oplog中的所有操作。所以理论上foo应该有16857个文档（7864个来自foo.bson，剩下的来自oplog.bson）。验证一下：

?

test:PRIMARY> db.foo.count()

16857

这就是带oplog的mongodump的真正作用。

?

1.2.3 从别处而来的oplog

?

聪明如你可能已经想到，既然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的开始时间。

?

?

?

明白了这个道理，理论上只要我们的mongodump做得足够频繁，是可以保证数据库能够恢复到过去的任意一个时间点的。MMS（现在叫Cloud Manager）的付费备份也正是在利用这个原理工作。假设oplog时间窗口有24小时，那么理论上只要我在每24小时内完成一次dump，即可保证dump之后的24小时的point-in-time数据恢复。在oplog时间窗口快要滑出24小时的时候，只要及时完成下一次dump，就又可以有24小时的安全期。

?

来做个测试。仍然使用前面的方法模拟一段时间的数据库插入操作：

?

use test

for(var i = 0; i < 100000; i++) {

? ? db.foo.insert({a: i});

}

同时做一次mongodump并不带--oplog:

?

yaoxing ~/dump $ mongodump -h 127.0.0.1?