MongoDb中的开发团队的生命副本

Question

问:用于测试和开发的生命版本的最佳架构是哪一种？

电流设置：

我们有两个amazon/EC2单神服务器，如下所示：

Machine A:
    A production database (on an amazon/EC2 server) (name it ‘PROD’)
    Other databases (‘OTHER’)

Machine B:
    a pre-production database (name it ‘PRE’)
    a copy for developer 1 own tests (call it ‘DEVEL-1’)
    a copy for developer 2 (DEVEL-2)
    …DEVEL-n

预数据库用于集成测试，然后部署到生产中。

对于每个开发人员来说，DEVEL都是在不打扰其他开发人员的情况下破坏自己的数据的。

我们不时地想要“恢复”新的数据从PROD到前和发展-n的基础。

目前，我们通过.copyDatabase()命令从PROD传递到PRE。然后我们发出.copyDatabase()“n”次，将副本从PRE复制到DEVEL。

的麻烦：

一个拷贝需要很长的时间(每次拷贝1小时，DBsize超过10 we )，而且通常它会使单神饱和，所以我们必须重新启动服务。

我们发现：

• 转储/恢复系统(如.copyDatabase()那样饱和)
• 复制集
• 主人/奴隶(似乎不受欢迎)

复制集似乎是胜利者，但我们有严重的疑虑：

假设我们想要一个副本集来将活的A/PROD同步到B/PRE (并且有A可能作为主服务器，B可能是次要的)：

( a)我能否从A中选择“几个”数据库来复制PROD，而不去复制其他数据库呢？

( b)我是否可以在B(如DEVEL)中拥有不在主数据库中的“额外”数据库？

( c)我是否可以“停止复制”，这样我们就可以部署到PRE，用新鲜数据测试软件，用测试破坏数据，并且在测试完成后“重新链接”副本，从而删除PRE中的更改，并将PROD中的更改适当地传送到PRE中吗？

( d)是否有比复制集更适合这种情况的方法？

谢谢。玛丽娜和哈维。

Answer 1

复制集似乎是胜利者，但我们有严重的疑虑： 假设我们想要一个副本集来将活的A/PROD同步到B/PRE (并且有A可能作为主服务器，B可能是次要的)： ( a)我能否从A中选择“几个”数据库来复制PROD，而不去复制其他数据库呢？

与MongoDB 2.4一样，复制始终包括所有数据库。设计意图是让所有节点最终成为一致的副本，这样您就可以在同一个副本集中的另一个非隐藏的次要节点上进行故障转移。

( b)我是否可以在B(如DEVEL)中拥有不在主数据库中的“额外”数据库？

不，复制集中只有一个主主。

( c)我是否可以“停止复制”，这样我们就可以部署到PRE，用新鲜数据测试软件，用测试破坏数据，并且在测试完成后“重新链接”副本，从而删除PRE中的更改，并将PROD中的更改适当地传送到PRE中吗？

由于只能有一个主组件，所以在同一个副本集中混合生产和测试角色的用例是不可能的。

最佳实践将隔离您的生产环境和开发/暂存环境，这样就不会出现意外的交互。

( d)是否有比复制集更适合这种情况的方法？

您可以采取一些方法来限制需要传输的数据量，这样您就不会每次从生产中复制完整的数据库(10 to )。副本集适合作为解决方案的一部分，但您需要为您的预环境提供一个独立的服务器或副本集。

一些建议：

• 在开发环境中使用副本集并添加隐次。您可以在不影响生产应用程序的情况下从此节点进行采取备份，而且由于次要的更改在发生时会复制，所以您应该对备份执行一个相对更快的本地网络副本。
• 根据MongoDB的可裁剪光标的oplog实现您自己的部分复制方案。本地oplog.rs上限集合是相同的机制，用于将更改中继到副本集的成员，并包括插入、删除和更新的详细信息。您可以匹配相关的数据库命名空间和中继匹配更改，从您的产品副本集到您的孤立的预环境。

这两种方法都允许您控制备份何时从PROD传输到PRE，以及测试后从前一点重新启动。

Answer 2

在我们的设置中，我们使用EBS快照在暂存环境上快速复制生产数据库。快照每隔几个小时运行一次，作为备份周期的一部分。在暂存中启动新的DB服务器时，它会查找最新的DB快照，并将其用于EBS驱动器。拍照几乎是瞬间的，恢复也是非常快的。这种方法也能很好地扩展，我们实际上在巨大的分片MongoDB安装中使用它。唯一的缺点是您需要依赖AWS服务来实现它。在某些情况下，这可能是不可取的。