我想设置一个实验来评估 Mongo 如何使用各种支持快照的技术来执行。
它需要受磁盘 IO 限制，因此我需要确保我的所有写入本质上都是同步的 - 否则我将需要创建一个违反 RAM 和交换约束的数据集，但我相信在每次插入时启用文件系统刷新将确保每个操作在下一个操作之前被刷新。
> db.runCommand({getlasterror:1,j:true})
我还能做些什么来真正锻炼 MongoDB 进程的 IO 特性？
我将测试诸如恒定插入率之类的东西，并观察该过程在以下期间的表现
我希望确保在活动和硬件保持不变的同时，遇到相对的性能基准。
感谢您的任何提示。
罗布，这太棒了。这样做的结果应该使每个人都受益。
我想指出一些在您测试 MongoDB 生产部署的典型快照操作期间可能会有所帮助的事情。
拍摄快照
正如您所指出的，在实时服务器上拍摄快照的主要问题是 IO 争用。为了避免这种情况，大多数人会部署一个包含 3 个以上成员的副本集。
通常，在这种情况下，其中一个辅助节点要么是 fsync 并在快照期间被锁定，要么配置为隐藏成员，要么只是脱机。这允许在热备份（另一个辅助节点）仍可用于自动故障转移时拍摄快照。
这也确保了另外两件事。首先，可以及时完成快照（生产负载不影响备份时间），其次，拍摄快照所需的负载不会影响生产读取（在允许从辅助节点读取的情况下——slaveOk） .
备份机制
以上关于快照策略的观点很重要，因为大多数人忽略了辅助节点与主节点具有相同写入负载的事实。
MongoDB 没有多主复制。在给定时间，只有一个服务器（在集合/分片中）可用于写入（主服务器或主服务器）。
但是，当主节点接收写入和读取时，辅助节点会跟踪该主节点的 oplog（一个上限集合）。辅助节点发出定期请求，以查看是否有更多数据等待从此可尾游标读取。当存在时，这些 oplog 条目将从主节点读取并写入（是的——这需要一个写锁）到辅助节点。
然后辅助节点将 oplog 中的新条目应用到它们自己的数据副本（是的——这需要写锁）。
您可能知道这一切，但在进行这项很棒的研究时请记住这一点。
祝你好运！