我最近推出了一个尚未看到太大生产规模的网络应用程序，但我希望（希望；）它会在不久的将来。
我发现使用db.copyDatabase()将当前生产系统的快照复制到开发中非常有用的能力，并且想知道随着生产数据库的增长/承受更重的负载，我可能会遇到什么样的问题。
文档似乎没有表明该命令正在阻塞（具体来说，如果在命令运行时将数据添加到任一数据库，则数据集的引用会变得不同步）。
由于数据库被复制到开发（或登台）服务器，重建索引/等所花费的时间不会是一个大问题（至少在一段时间内）。
在这种情况下，文档对指导方针有点了解，所以我希望得到以下方面的建议：
作为参考，应用程序和数据库是分开托管的（heroku / mongolab）。我还在命令db.dropDatabase()之前在本地运行copyDatabase()以获取全新的数据库。
不确定您是否知道，但您可以通过 MongoLab 的 Web 界面安排一次性或定期备份。这些备份可以转到您自己的自定义云存储容器（例如 Amazon S3），或者您可以选择让 MongoLab 将其存储在其云存储容器之一中。
这些备份是二进制转储（通过 MongoDB 的 mongodump 工具获取），您可以直接从 MongoLab 的 UI 下载它们。
我们将所有数据库复制到共享实例上，并尽一切努力从辅助数据库中取出备份，以最大程度地减少主数据库的负载（备份可能会占用大量资源）。
希望有帮助。
这个答案最终会有点主观，因为我们不在您的硬件上等。
运行 db.copyDatabase 从生产中的实时数据库复制是否合适？
二进制备份可能是更好的选择：docs.mongodb.org/manual/tutorial/backup-databases-with-binary-database-dumps/
考虑到它基本上是使用全表扫描的数据库的“副本”，它的效果与真正从应用程序中执行完全相同的效果相同。如果您的数据不一定适合您的 RAM，它可能会导致临时过多的工作集，甚至可能导致计算机 LRU 内的交换。
通常情况下，您的工作集并不代表实际提取所有数据的成本，并且由于虚拟内存（mmap 进入）不是 RAM，您可能会发现它不适合。
除了 RAM 问题之外，您还可能会遇到很多很多因素的读取锁定问题。基本上有一些东西要记住。
我确信还有更多我没有列出的问题。
然而，值得一提的是，这些问题中的大多数都存在于一个非常大的数据集上。
超过它不再可行的大小是否有实际限制？
这完全取决于您准备等待数据多长时间以及您的服务器可以处理多少工作集，但我可能会选择链接问题的场景并说 100GB 是一个很好的限制.