mongodb系列之-解读journal

      mongodb的journal，简单来说就是用于数据故障恢复和持久化数据的，它以日志方式来记录。从1.8版本开始有此功能，2.0开始默认打开此功能，但32位的系统是默认关闭的。

    journal除了故障恢复的作用之外，还可以提高写入的性能，批量提交（batch-commit），journal一般默认100ms刷新一次，在这个过程中，所有的写入都可以一次提交，是单事务的，全部成功或者全部失败，刷新时间，可以更改，范围是2-300ms。

       当系统非正常情况下突然挂掉，再次启动时候mongodb就会从journal日志中恢复数据，而确保数据不丢失，最多丢失s级别的数据（个人臆想），具体为什么，看看一下便知：

    使用db.serverStatus（）可以查看状态：

   

dur:{
		commits:30,
		journaledMB:0.270336,
		writeToDataFilesMB:0.329578,
		compression:0.7986268873651776,
		commotsInWriteLock:0,
		earlyCommits:0,
		timeMs:{
			dt:3077,
			prepLogBuffer:0,
			writeToJournal:4,
			writeToDataFiles:3,
			remapPrivateView:3
		}
}

dur.timeMS.prepLogBuffer：从privateView映射到Logbuffer的时间。

 

dur.timeMS.writeToJournal：从logbuffer刷新到journalfile 的时间。
dur.timeMS.writeToDataFiles：从journalbuffer映射到MMF，然后从MMF刷新到磁盘的时间，文件系统和磁盘会影响写入性能。 
dur.timeMS.remapPrivateView：重新映射数据到PrivateView的时间，越小性能越好。

所以说开启journal后会使用更多内存，因为journal会另外使用一块内存区域（即：PrivateView）

 

再来看看开启journal后，在mongodb上读写数据和读数据的一个大致流程（画的很粗略）：

 

 

link see:http://blog.mongodb.org/post/33700094220/how-mongodbs-journaling-works

 

The last step is that mongod remaps the shared view to the private view. This prevents the private view from getting too “dirty” (having too many changes from the shared view it was mapped from).

 

 从而我们可以得知，如果服务器突然宕机，那么丢失的数据也会很少，因为默认100ms journal数据就会被sync到文件中。

 

 一般来说，对于重要的数据来说，我个人建议开启此功能，以免丢失