對生產mongo數據庫運行db.copyDatabase（）會有什麼樣的性能影響？

Question

我最近推出了一個網絡應用程序，目前還沒有看到太多的生產規模，但我預計（希望;）它將在不久的將來。

我發現能夠使用db.copyDatabase()將當前生產系統的快照複製到開發中非常有用，並且想知道隨着生產數據庫增長/處於較重負載下，可能遇到什麼樣的問題。

文檔似乎並未顯示該命令是阻塞的（具體來說，如果在命令運行時將數據添加到任一數據庫，則數據集的引用會不同步）。

由於數據庫正在複製到dev（或staging）服務器，所以重建索引/ etc所花的時間不會是一個大問題（至少在一段時間內）。

的文檔是在這種情況下指南略顯清淡，所以我希望得到的建議上：

• 是否適當從在生產現場數據庫運行db.copyDatabase複製？
• 源數據庫是否存在性能問題？
• 過去的大小是否有實際限制？ （基於this question here，該限制似乎是相當大的）

作爲參考，該應用和數據庫分別託管（heroku/mongolab）。我在copyDatabase()命令之前在本地運行db.dropDatabase()以獲得完全新的數據庫。

Answer 1

這個答案最終會是一個有點主觀的，因爲我們不是你的硬件等

是否適合運行db.copyDatabase從活動數據庫在生產複製？

二進制備份可能是更好的選擇在這裏：docs.mongodb.org/manual/tutorial/backup-databases-with-binary-database-dumps/

考慮，它基本上是一個「副本「使用全表掃描的數據庫，它將具有與從應用程序完全相同的效果。它可能會導致一個臨時的過度工作集，甚至可能導致計算機內的交換LRU，如果您的數據不適合您的RAM。

可能會出現這種情況，您的工作集並不代表實際帶出所有數據需要花費多少成本，並且由於虛擬內存（其中mmap指向的內存）不是內存，您可能會發現它不會「不適合。

除了內存問題，你可以通過獲取讀取鎖定問題，這取決於許多因素。基本上在那裏想到的東西。

我相信還有更多的問題我沒有列出。

但是應該很好的提及這些問題中的大多數存在於非常大的數據集中。

是否有一個實際限制的大小過去，它停止可行？

這一切都取決於你準備等待數據多長時間，以及你的服務器可以處理多少工作集，但我可能會用鏈接問題的場景，並說100GB是一個很好的限制。

Answer 2

不知道，如果你知道，但你可以安排通過MongoLab的Web界面一次性或定期備份。這些備份可以轉到您自己的自定義雲存儲容器（例如Amazon S3），或者您可以選擇讓MongoLab將其存儲在其中一個雲存儲容器中。

這些備份是二進制轉儲（通過MongoDB的mongodump工具拍攝），你可以從MongoLab的UI直接下載。

我們複製所有的數據庫的共享實例，並盡一切努力，採取備份過二級的，以儘量減少對初選負載（備份可以相當資源密集）。

希望有所幫助。