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

Tun*_*yen 4 sync mirror mongodb replay

我们在生产环境中运行一个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结构(再添加一个节点).这些变化严重影响了replset.

谢谢.

Ost*_*our 7

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

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

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