我们在生产环境中运行一个由3个成员组成的MongoDB副本集。
我们需要维护该 replset 的克隆，称为"镜像"，以进行内部分析。此镜像不需要是实时的，但它越是最新的越好(最多可能滞后 1 天(。
维护这种镜像数据库的最合适方法是什么？(请注意，此镜像可以是 1 个成员的 replset 或独立实例(
仅供参考，我们尝试了 2 个选项，但它们的速度是不可接受的：
- Oplog重播。但这花费了太多时间(~40 小时才能从 replset 的 Primary 中播放 oplog(。
- 定期使用来自生产 replset 的快照，但新卷(从快照创建(非常慢，因为它没有预热(我们正在使用 AWS EBS，预热需要 ~12 小时(
Update #1：我们还尝试将镜像作为 replset 成员，但我们想将镜像与 replset 分开，因此此选项不满足要求。
Update #2：我们不希望此镜像成为 replset 成员的原因：我们在此镜像上运行了大量查询，并使其耗尽了资源积分(磁盘 IO、网络 IO、CPU(，并且实例暂时不可用。这改变了整个 replset 结构(因为它丢失了一个节点(。当实例再次可用时，它再次更改了 replset 结构(再添加一个节点(。这些变化严重影响了重新设置。
谢谢。
"隐藏的次要"，如下所述：http://docs.mongodb.org/manual/tutorial/configure-a-hidden-replica-set-member/
我们在分片副本环境(4 个分片，每个分片多个辅助副本(中使用它们来执行备份。我们关闭隐藏的辅助数据库，拍摄文件系统的快照，然后启动计算机。在备份期间/之后，生产群集从未出现问题。根据您的需要，您可以将延迟设置为自定义时间，以便副本处于活动状态或具有配置的延迟。
更新：为了解释为什么我如此确定这将起作用：我们的集群(以MongoDB规模(完成了非常繁重的工作，具有巨大的M/R作业，高插入，更新和查询速率以及大约10TB的总数据库大小。所有这些都在相当小的 EC2 实例上。我们可以在生产集群的任何状态下关闭备份辅助数据库，而不会出现任何问题。一年多来，我们每天进行 5 次以上的备份，并对架构进行了多次测试。从未在生产集群上看到任何问题。由于我们的应用程序确实对延迟敏感，如果在备份期间有任何延迟影响，我们将看到系统产生巨大影响。
您可以设置 mongodb 以对定义的节点进行读取首选项：http://docs.mongodb.org/manual/core/read-preference/#tag-sets、http://docs.mongodb.org/manual/tutorial/configure-replica-set-tag-sets/。使用标签并不复杂，并且是"最近"读取首选项的很好的替代方案。
因此，您可以将此"镜像"作为副本集的从属成员，并使用标记 "production" ，以便生产客户端从生产辅助节点读取数据，并且仅在需要从此实例读取时使用特殊标记"mirror"此"镜像"实例。以这种方式的镜像实例将成为副本的完整成员，并将不断更新。在这种情况下，此"镜像"实例的延迟副本集成员也有意义。
但是，有一点需要考虑：
当读取首选项包含标记集时，客户端会尝试查找与指定标记集匹配的辅助成员，并将读取定向到最接近组中的随机辅助成员。如果没有辅助数据库具有匹配的标记，则读取操作将生成错误。[1]
无论如何，我会尝试代替你这样做。
附言关于在MongoDB上收集集合的统计信息和分析的重要事项。这些课程中的Mongodb专家建议在写入操作期间\存储计数等统计信息：这意味着，如果你有一些用户集合，你必须为每个用户计算一些帖子或其他一些统计的东西，一系列写入与一些计数器***字段的$inc将涂抹数据库上的负载，整体性能会更好，如果你每次需要使用复杂的聚合请求，你需要计算一些东西或从数据库获取平均值或执行类似的统计请求。