Mongodb在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。持久化为了保证数据永久保存不丢失。MongoDB具有高度可配置的持久化设置，从完全没有任何保证到完全持久化。下面介绍一下内容：1. MongoDB是如何保证持久化的2. 如何配
Mongodb在1.8版本之后开始支持journal，就是我们常说的redo log，用于故障恢复和持久化。
持久化为了保证数据永久保存不丢失。MongoDB具有高度可配置的持久化设置，从完全没有任何保证到完全持久化。下面介绍一下内容：
1. MongoDB是如何保证持久化的
2. 如何配置应用程序和服务器持久化等级来满足你的需求
3. 没有启用journal的影响
4. 什么是MongoDB保证不了的
MongoDB可以保证当服务器崩溃或服务器硬关机或硬盘故障时的数据完整性。在关系型数据库中通常是使用事务来保证数据的持久性。MongoDB是不支持事务的，那么是如何来保证的呢？
1. Journaling是干什么的
MongoDB journaling 工作原理
当执行写操作时，MongoDB创建一个journal来包含确切磁盘位置和改变的字节。因此，如果服务器突然崩溃，启动时，journal会重放崩溃前并没有刷新到磁盘上的任何写操作。
数据文件每隔60s刷新到磁盘上，默认情况下，因此journal只需要持有60s内的写入数据。journal预分配了几个空文件用于此目的，位于/data/db/journal，命名为_j.0,j.1等等。
MongoDB运行很长时间情况下，在journal目录下，你会看到类似于_j.6217,_j.6218和_j.6219文件。这些文件是当前的journal文件，如果MongoDB一直运行，这些数字会持续增加。当正常关闭MongoDB时，这些文件将被清除，因为正常关机不在需要这些日志的。
如果服务器崩溃或kill -9, mongodb再次启动时，会重放journal文件，会输出冗长难懂的检验行，这表明在正常的恢复。
1.1 有规划的批提交
默认情况下，MongoDB每隔100ms写入一次journal日志，几兆字节的数据被写入。这意味着mongodb批量提交更改，每个写不立即刷新到磁盘，但是默认设置，你不可能失去写入超过100ms的数据，在每个崩溃事件中。
然而，这种保证对某些应用不是足够强，所以有几种方法可以得到更强的持久化保证。你可以通过把j选项传递给getLastError来确保写入已经写入持久化。getLastError会等待上一次的写操作写入到journal和journaling只会等待30ms而不是100ms，journal下一批写。
> db.foo.insert({"x" : 1})
> db.runCommand({"getLastError" : 1, "j" : true})
> // The {"x" : 1} document is now safely on disk
请注意：如果每次写使用 "j" : true，意味着写的速度将基本控制在 33 writes/sec。(1 write/30ms) × (1000ms/second) = 33.3 writes/second
这一般并不需要太长的时间来刷新写入到磁盘，因此你会发觉写性能提高了，如果你允许mongodb批量大多数写，而不是一个一个的提交。该选项用在重要的写入操作。
提交之前已经提交过的写也是一样的，因此，如果有50个重要的写操作，可以使用“normal” getLastError 不带j选项，然后在最后的一个写操作用j选项，如果成功的，说明50个写操作被安全的刷新到磁盘了。
如果连接了多个写连接，可以使用j选项来并行写入，提高吐吞量，即使延迟高。
1.2 设置提交间隔
为了journaling侵入程度降低的另一种选择是，缩短或延长两者之间的journal提交。执行setParameter 命令来设置journalCommitInterval 值为2ms到500ms之间的值。下面设置journal每隔10ms提交：
> db.adminCommand({"setParameter" : 1, "journalCommitInterval" : 10})
该选项也可以在启动时设置 --journalCommitInterval。
不管间隔设置，调用getLastError "j" : true 时间将减少到三分之一。
如果客户端尝试写入速度比journal刷新快，mongodb将被阻塞，直到journal完成写入磁盘。
关闭journaling以及其他内容参见下节内容。
原文地址：mongodb 持久化(1), 感谢原作者分享。
