4

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

当前设置：

我们有两个这样的 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，但不考虑 OTHER？

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

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

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

谢谢。玛丽娜和哈维。

4

2 回答 2

1

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

假设我们想要一个副本集将实时 A/PROD 同步到 B/PRE（并且 A 可能作为主要，B 可能作为次要）：

a) 我可以从 A 中选择“一些”数据库来复制 PROD，但不考虑 OTHER？

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

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

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

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

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

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

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

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

一些建议：

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

于 2013-04-13T13:52:01.367 回答
0

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

于 2013-01-22T18:04:39.157 回答