我想要設置一個實驗來評估Mongo如何使用各種能夠創建快照的技術執行操作。如何在使用各種快照技術時測試MongoDB的相對性能
它需要的磁盤IO約束，所以我需要以確保我的所有寫入在本質上是同步的 - 否則我將需要創建一個會破壞RAM和交換約束的數據集，但我相信啓用文件系統刷新每一次插入操作都會確保每次操作在下一次操作之前都被刷新。
> db.runCommand({getlasterror:1,j:true})
我還能做些什麼才能真正實現MongoDB進程的IO性質？
我將測試類似不斷插入率和在下列期間
我正在尋找以確保在活動和硬件保持不變的同時，還會遇到相對的性能基準。
感謝您的任何提示。
Rob，這太好了。這樣做的結果應該有利於每個人。
我想說明一些在測試MongoDB生產部署的典型快照操作時可能會有幫助的事情。
拍攝快照
與採取現場服務器上的快照，正如你指出的主要問題，是IO爭。爲了避免這種情況，大多數人都會部署一個擁有3個以上成員的副本集。
通常，在這種情況下，其中一個輔助節點是fsync並在快照過程中鎖定，配置爲隱藏成員，或者只是脫機。這允許在熱備份（另一個備份）仍然可用於自動故障轉移時執行快照。
這也確保了另外兩件事。首先，可以及時完成快照（生產負載不影響備份時間），其次，生成快照所需的負載不會影響生產讀取（在允許從輔助數據讀取的情況下 - slaveOk） 。
備份力學
有關快照策略上面一點很重要，因爲大多數人都忽略了一個事實次級具有相同的寫入負載作爲主。
MongoDB沒有多主複製。只有一個服務器（在set/shard中）在給定時間處於寫入狀態（主服務器或主服務器）處於活動狀態。
但是，雖然主服務器正在接收寫入和讀取操作，但輔助服務器會終止該主服務器的oplog（上限集合）。次要用戶定期發出請求，以查看是否有更多數據等待從此可拖動光標讀取。如果存在，那些oplog條目將從主節點讀取並寫入（是 - 這需要寫入鎖定）到輔助節點。
然後輔助人員將oplog中的新條目應用到他們自己的數據副本（是的 - 這需要寫入鎖定）。
你可能知道所有這些，但只是在做這個真棒研究時記住它。
祝你好運！
上託管我們的應用程序。我們還沒有弄清楚這一點，但我們可能會在未來測試它，計劃 - 目前所有的數據都通過非常原始的方式（mongodump）快速備份，沒有應用程序影響。 – 2012-10-01 09:47:37
如何使用您的實際應用程序？ – 2012-04-26 20:35:44
@John，當然很好。道歉，我忽略提及該應用程序尚未編寫。這個實驗實際上構成了是否使用和依賴EBS快照的基礎，或者是否爲另一個不提供卷快照的雲提供商。如果我們能夠打好測試平臺，它將有助於對我們選擇的平臺做出明智決定，以便我們選擇在 – 2012-04-27 09:38:39