维护MongoDB副本集的镜像数据库

Question

我们在生产环境中运行一个3人的MongoDB副本集。

我们需要维护该replset的克隆，称为“镜像”，以进行内部分析。这个镜子不需要是实时的，但它越新越好（可能是最大的1天滞后）。

维护这样一个镜像数据库最合适的方法是什么？ （请注意，此镜像可以是1个成员的replset或独立实例）

仅供参考，我们尝试了两种选择但速度不可接受：

1. Oplog重播。但是这需要花费很多时间（从replset的Primary中播放oplog大约需要40个小时）。
2. 定期使用生产replset中的快照，但新卷（从快照创建）非常慢，因为它没有预热（我们使用的是AWS EBS，预热需要大约12个小时）

Update #1：我们还尝试将镜像作为replset成员，但我们想将镜像与replset分开，因此这些选项不满足要求。

Update #2：我们不希望这个镜像成为replset成员的原因：我们在这个镜像上运行了大量查询并使其耗尽资源信用（磁盘IO，网络IO，CPU）和实例暂时不可用。这改变了整个replset结构（因为它丢失了一个节点）。当实例再次可用时，它再次更改了replset结构（再添加一个节点）。这些变化严重影响了重新设置。

谢谢。

Answer 1

您可以使用＆＃34;隐藏的辅助＆＃34;如下所述：http://docs.mongodb.org/manual/tutorial/configure-a-hidden-replica-set-member/

我们在分片副本环境中使用它们（4个分片，每个分片有多个辅助副本）来进行备份。我们关闭隐藏的辅助节点，拍摄文件系统的快照并在此之后启动机器。备份期间/之后从未在生产群集上出现问题。 根据您的需要，您可以将延迟设置为自定义时间，以使副本处于活动状态或具有已配置的延迟。

<强>更新 解释为什么我确信这会起作用： 我们的集群（在MongoDB规模上）确实非常繁重，具有巨大的M / R作业，高插入，更新和查询率以及大约10TB的总DB大小。所有在相当小的EC2实例上。我们可以在生产群集的任何状态下关闭我们的备份辅助副本而不会出现任何问题。我们每天进行超过5次备份超过一年，并对该架构进行了多次测试。从未在生产集群上看到任何问题。由于我们的应用程序确实对延迟敏感，如果在备份期间存在任何类型的延迟影响，我们会在系统中看到巨大的影响。

Answer 2

您可以设置mongodb以对已定义的节点进行读取首选项：http://docs.mongodb.org/manual/core/read-preference/#tag-sets，http://docs.mongodb.org/manual/tutorial/configure-replica-set-tag-sets/。使用标签并不复杂，是“最近”读取偏好的替代品。

因此，您可以将此“镜像”作为副本集的从属成员，并使用标记"production"，让生产客户端从生产辅助节点读取，并使用特殊标记"mirror"这个“镜像”实例仅在您需要从此实例中读取时。这种方式的镜像实例将是副本的完整成员，并将不断更新。这个“镜像”实例的Delayed replica set member在这种情况下也有意义。

然而，有一点需要考虑：

  

当读取首选项包含标记集时，客户端会尝试查找与指定标记集匹配的辅助成员，并将读取指向最近的组中的随机辅助。如果没有辅助节点具有匹配的标签，则读取操作会产生错误。 [1]

无论如何，我会试着在你的位置上这样做。

P.S。关于在MongoDB上收集集合的统计信息和分析的一个重要事项。 Mongodb Experts in those courses建议在写操作期间存储诸如计数等统计数据： 这意味着，如果你有一些用户集合，你必须为每个用户或其他一些统计的东西计算一些帖子，用$ inc写入一些计数器字段的系列会涂抹数据库上的负载，整体性能会更好然后，如果您每次需要计算某些内容或获得平均值或从数据库执行类似的统计信息请求时使用复杂的聚合请求。