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

Question

问:对于用于测试和开发的生命副本，哪种架构是最好的？

当前设置:

我们有两个这样的 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。 然后我们发出“n”次 .copyDatabase() 以从 PRE 复制到 DEVEL-n。

问题:

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

我们发现了:

• 转储/恢复系统(像 .copyDatabase() 一样饱和)
• 副本集
• 主/从(似乎已弃用)

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

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

a) 我可以从 A 中选择“几个”数据库来复制 PROD 而让其他数据库保持不变吗？

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

c) 我可以“停止复制”以便我们可以部署到 PRE，用新数据测试软件，用测试丢弃数据，在测试完成后“重新链接”副本以便在 PRE 中更改被删除并且 PROD 中的更改被充分传输到 PRE 中？

d) 是否有比副本集更适合这种情况的其他方法？

谢谢。 玛丽娜和哈维。

Answer 1

Replica-sets seem the winners, but we have serious doubts:

Suppose we want a replica-set to sync live A/PROD into B/PRE (and have A likely as a primary and B likely as secondary):

a) Can I select “a few” databases from A to replicate PROD but leave OTHER alone?

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

b) Can I have “extra” databases in B (like DEVEL-n) which are not in the master?

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

c) Can I “stop to replicate” so we can deploy to PRE, test the soft with fresh-data, trash the data with the testing and after tests have been complete “re-link” the replica so changes in PRE are deleted and changes in PROD are transported into PRE adequately?

因为只能有一个主节点，所以在同一个副本集中混合生产和测试角色的用例不可能像您想象的那样。

最佳做法是隔离您的生产和开发/暂存环境，以免发生意外交互。

d) Is there any other better way than replica-sets suitable for this case?

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

一些建议:

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

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

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