我们在生产环境中运行一个 3 成员的 MongoDB 副本集。
我们需要维护该 replset 的一个克隆，称为“镜像”，以进行内部分析。这个镜像不需要是实时的，但它越新越好(最多可以延迟 1 天)。
维护这样一个镜像数据库最合适的方法是什么？ (请注意，此镜像可以是 1-member replset 或独立实例)
仅供引用，我们尝试了 2 个选项，但它们的速度 Not Acceptable :
- 重放操作日志。但这花了很多时间(大约 40 小时从 replset 的主节点播放 oplog)。
- 定期使用来自生产 replset 的快照，但新卷(从快照创建)非常慢，因为它没有预热(我们使用的是 AWS EBS，预热大约需要 12 小时)
更新 #1:我们也尝试让镜像成为 replset 成员，但我们想将镜像与 replset 分开，所以这个选项不满足要求。
更新 #2:我们不希望此镜像成为 replset 成员的原因:我们在此镜像上运行大量查询并使其耗尽资源信用(磁盘 IO、网络 IO , CPU) 并且实例暂时不可用。这改变了整个 replset 结构(因为它丢失了一个节点)。当实例再次可用时，它再次更改了 replset 结构(增加了一个节点)。这些更改严重影响了 replset。
谢谢。
最佳答案
您可以使用此处解释的“隐藏辅助”:http://docs.mongodb.org/manual/tutorial/configure-a-hidden-replica-set-member/
我们在分片副本环境(4 个分片，每个分片多个辅助)中使用它们来进行备份。我们关闭隐藏的辅助服务器，拍摄文件系统的快照，然后启动机器。在备份期间/之后，生产集群上从未出现过问题。 根据您的需要，您可以将延迟设置为自定义时间，以便副本处于事件状态或具有配置的延迟。
更新: 解释为什么我如此确定这会起作用: 我们的集群确实(以 MongoDB 规模)处理大量的 M/R 作业、高插入、更新和查询率以及大约 10TB 的总数据库大小。全部在相当小的 EC2 实例上。我们可以在生产集群的任何状态下毫无问题地关闭我们的备份辅助节点。一年多来，我们每天备份 5 次以上，并对架构进行了多次测试。从未在生产集群上看到任何问题。由于我们的应用程序确实对延迟敏感，如果在备份期间存在任何类型的延迟影响，我们将看到对我们系统的巨大影响。
关于mongodb - 维护 MongoDB 副本集的镜像数据库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27522500/