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到文件中。

 

 一般來說，對於重要的數據來說，我個人建議開啓此功能，以免丟失

 

 

 

 

 

• 大小: 22.6 KB

• 查看圖片附件