单甘可靠性

Question

我知道备份MongoDB数据的推荐方法是使用文件系统级别的工具。但是，当文件系统快照由于某种原因而不可用时，mongodump实用程序被提升为较小实例的有效替代。许多资源建议使用-oplog选项来运行它，以启用实时恢复。

我试图理解-oplog如何在不需要数据库引擎的多版本并发控制的情况下启用实时快照。我认为只有以下几种方式才能奏效：

1. 我们假定所有集合中的_id值都是单调增加的。
2. 块在oplog中写入和记录最后一个操作id。
3. 通过按递减顺序导航_id索引，蒙蒂甘开始从所有集合中转储文档
4. 转储启动后，mongodump将对集合进行写操作。
5. 我们假设从现在开始所有的插入都有更高的_id值，并且只会出现在oplog中，而不是集合转储中。

如果_id值没有单调增加，或者写锁没有实现，并且存在争用条件，系统就会很快崩溃。此外，也不支持次要唯一索引。

据我所见，以下语句是正确的，这意味着mongodump不可能启用实时恢复，因此它的规范在其类似快照的功能方面具有误导性：

1. 即使内置的_id值生成器也不能保证总顺序。
2. 蒙蒂甘不发出任何写锁。
3. mongodump不按降序遍历_id索引，因此插入的记录将同时出现在集合转储和oplog中。

我的理解正确吗？在-oplog选项中有什么价值吗？

以下是我的建议：

1. https://jira.mongodb.org/browse/SERVER-24231
2. https://jira.mongodb.org/browse/TOOLS-176

Answer 1

我的理解正确吗？在-oplog选项中有什么价值吗？

由于MongoDB Blog文档，这里确保mongodump创建数据库的转储，其中包含包含自mongodump操作持续时间以来的操作的部分oplog。此oplog生成单神实例状态的有效实时快照。若要还原到特定的实时备份，请结合mongorestore --oplogReplay使用此选项创建的输出。如果没有-oplog，如果在转储操作中有写操作，转储将不会反映一个时刻。在更新过程中对数据库所做的更改会影响备份的输出。

当对mongos实例运行mongodump以转储已分片集群的全部内容时，--oplog没有任何效果。但是，您可以使用--oplog来转储单个碎片。

--oplog只对维护oplog的节点起作用。这包括副本集的所有成员，以及主/从复制部署中的主节点。

--oplog不转储oplog集合。

我知道备份MongoDB数据的推荐方法是使用文件系统级别的工具。但是，当文件系统快照由于某种原因而不可用时，mongodump实用程序被提升为较小实例的有效替代。许多资源建议使用-oplog选项来运行它，以启用实时恢复。

如果要备份所有DB，可以使用oplog选项。

mongodump  --oplog --out /dump_location

现在，在恢复过程中，可以这样做：

mongorestore --oplogReplay

这样，mongodump就不需要写锁了。在备份过程中进行的任何写入都将写入oplog.bson。在恢复时，mongorestore将使用这个oplog来包含写操作。

进一步参考这里，这里和这里