6、必须将数据写刷新到磁盘。 如果磁盘利用率达到了100%，那么处理更多写操作的速度比起现在得不到丝毫的提升。可以通过MMS中的“Background flush average”图表查看将数据文件中的脏页刷新到磁盘花费了多长时间。通过这种趋势你会发现，随着写操作的增长，刷新将花费更多的时间。这种问题可以通过使用更快的磁盘解决，将工作拆分到更多的分片上，或者调整应用程序使之减少写数据的总量。你应该记住：写入的所有内容都会被刷新到磁盘两次——立即刷新到日志同时周期性地刷新到数据文件。将这两种操作分离到不同的物理设备上将会消除它们对可用磁盘IO带宽的竞争。
7、复制 != 备份。 所有人都清楚备份的重要性。但是为什么备份这么重要呢？ 想必是因为当某些影响所有复制集节点的灾难性事件发生的时候我们可以恢复数据。复制并不是备份的原因是：它并不能让你避免人为错误——例如某些人突然删除了产品数据，或者部署了错误版本的应用程序代码以致于搞乱了部分或者所有数据。必须要有一个能够让我们从这种场景中恢复数据的备份。通过文件系统快照、mongodump或者MMS备份练习数据恢复。第一次从备份恢复产品数据的操作不应该发生在真正的“数据紧急事件”发生的时候。 8、复制集的健康不仅仅是复制延迟。 “复制延迟”仅仅是复制集健康状况的指标之一。关注复制操作日志（oplog）窗口和监控复制延迟一样重要。它表示的是基于现在的写流量完全“滚动”oplog所要花费的时间。换句话说，它指的是将一个复制节点拿下来以后依然能够重新加入集合而不必对所有数据进行重新同步的时间。随着时间的推移，复制操作日志窗口将会随着写负载的变化而浮动。流量高峰时窗口会缩短。这在容量计划中是非常重要的，你需要为最繁忙的数据吸收时间做好准备。下面是MMS中的一个并行视图，它展示了整个复制集的复制操作日志窗口。
9、MongoDB并不清楚数据需要什么样的安全级别。 和其他数据库一样，你应该遵循最小特权原则。必须自己配置数据库的安全。不要让所有人都能访问你的数据。打开MongoDB自己本身的安全机制是非常重要的，但是这样也锁定了从任何地方对集群的访问，除非你确实认为自己的客户端进程可以在那里运行。只修改MongoDB进程的默认端口并不能保证安全。 10、没必要修改引擎里面的东西。 除非文档或者MongoDB支持告诉你做一些非常特殊的事情，否则你没有必要直接修改系统集合、本地、管理或者配置数据库。你可以借助于管理命令和shell执行所需的操作，如果数据库并不能按照期望运行，或者某些地方发生了错误，那么成功的钥匙并不是试图通过直接操作内部的“bits”强制它运行。你需要熟悉的唯一一个“特殊的”、由系统产生的集合是分析器集合，定期地分析你的查询是确保事情按照期望运行的一个非常好的方式。 来自：infoq |
