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