我想要设置一个实验来评估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