6

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

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

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

仅供参考，我们尝试了 2 个选项，但它们的速度不可接受：

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

Update #1: 我们也尝试让镜像成为 replset 成员，但是我们想将镜像从 replset 中分离出来，所以这个选项不能满足要求。

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

谢谢你。

4

2 回答 2

8

您可以使用此处解释的“隐藏辅助”：http: //docs.mongodb.org/manual/tutorial/configure-a-hidden-replica-set-member/

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

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

于 2014-12-27T22:33:04.560 回答
1

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

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

不过有一点需要考虑：

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

无论如何，我会尝试代替你这样做。

PS 关于在 MongoDB 上收集统计数据和分析您的集合的一件重要事情。这些课程中的Mongodb 专家建议在写入操作期间存储诸如计数等统计信息：这意味着，如果您有一些用户集合，则必须为每个用户计算一些帖子或其他一些统计信息，使用 $inc 进行一系列写入一些计数器***字段会涂抹数据库上的负载，如果您每次需要计算某些东西或从数据库获取平均值或执行类似的统计请求时都使用复杂的聚合请求，那么整体性能会更好。

于 2014-12-26T13:53:34.760 回答