mongodb - MongoDb 中开发团队的生活副本

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

当前设置:

我们有两个像这样的 amazon/EC2 mongod 服务器:

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

PRE 数据库用于在部署到生产之前进行集成测试。

DEVEL-n 是为了让每个开发人员在不打扰其他开发人员的情况下破坏自己的数据。

有时，我们希望将 PROD 中的新数据“恢复”到 PRE 和 DEVEL-n 库中。

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

麻烦:

一个副本需要很长时间(每个副本 1 小时，DBsize 超过 10GB)并且通常它会使 mongod 饱和，因此我们必须重新启动服务。

我们发现了关于:

转储/恢复系统(如 .copyDatabase() 那样饱和)

副本集

主/从(似乎已弃用)

副本集似乎是赢家，但我们有严重的疑虑:

假设我们想要一个副本集将实时 A/PROD 同步到 B/PRE(并且 A 可能是主要的，B 可能是次要的):

a) 我可以从 A 中选择“几个”数据库来复制 PROD 而不要管 OTHER 吗？

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

c) 我可以“停止复制”以便我们可以部署到 PRE，使用新鲜数据测试软件，通过测试删除数据，并在测试完成后“重新链接”副本以便删除 PRE 中的更改和PROD 的变化是否充分传输到 PRE 中？

d)除了适合这种情况的副本集之外，还有其他更好的方法吗？

谢谢。
玛丽娜和哈维。

最佳答案

在 MongoDB 2.4 中，复制始终包括所有数据库。设计意图是让所有节点成为最终一致的副本，以便您可以故障转移到同一副本集中的另一个非隐藏辅助节点。



不，副本集中只有一个主节点。



由于只能有一个主节点，因此在同一个副本集中混合生产和测试角色的用例是不可能的。

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



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

一些建议:

使用副本集并在您的开发环境中添加一个 hidden secondary。您可以从该节点使用 take backups 而不影响您的生产应用程序，并且由于辅助副本会在发生更改时复制更改，因此您应该对备份进行相对较快的本地网络复制。

根据 MongoDB 的 tailable cursor 的 oplog 实现您自己的部分复制方案。本地 oplog.rs 上限集合与用于将更改中继到副本集成员的机制相同，并包括插入、删除和更新的详细信息。您可以匹配相关的 database namespaces 并将匹配的更改从生产副本集传递到隔离的 PRE 环境中。

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

关于mongodb - MongoDb 中开发团队的生活副本，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14461903/