mongodb Journal工作原理
阿新 • • 發佈：2019-02-03
先介紹一下Journal：
journal檔案在MongoDB中的作用相當於redo日誌檔案在oracle中的作用，它可以在即使伺服器意外宕機的情況下，將資料庫操作進行重演。
在64位的機器上，2.0以上版本預設是開啟了journal的，但是在32位機器上，或者2.0以下的版本中，預設是不開啟journal的。所以在我的安裝了2.4.3版本的32位機器上，每次啟動mongodb都提示“warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.”，所以我須要在啟動mongodb時帶上 --journal 引數；而在預設啟動journal的機器上如果不想啟動journal，則可以帶上 --nojournal 引數。
第一次啟動帶啟用journal的服務前，通常磁碟上是沒有journal file的，這時mongodb就會現在磁碟上為journal檔案分配磁碟空間，這個過程會花比較長的時間（所以老師的視訊演示中，第一次啟動服務時花了很長的時間），在這段時間內服務是不可用的。如果想避免這個預分配動作也是可以的，就是從別的mongodb例項中拷貝一個已經預分配的檔案，然後放到自己的journal路徑中，這個預分配檔案是不含資料的，因此是這種操作方式是安全的。另外，我在網上看到有人說如果採用ext4的檔案系統，這個預分配的時間就會減小很多（據說ext4在ext3基礎上效能的提高，比ext3在ext2基礎上效能的提高要高不少），可惜我在嘗試做這個實驗時，嘗試了幾次把虛擬機器CentOS上的ext3檔案系統轉為ext4都沒有成功，所以最終放棄了這個實驗，希望如果有人做了這個實驗的話，將過程分享分享。
預設情況下mongodb每100毫秒往journal檔案中flush一次資料，不過這是在資料檔案和journal檔案處於同一磁碟捲上的情況，而如果資料檔案和journal檔案不在同一磁碟捲上時，預設重新整理輸出時間是30毫秒。不過這個毫秒值是可以修改的，可修改範圍是2~300，值越低，重新整理輸出頻率越高，資料安全度也就越高，但磁碟效能上的開銷也更高。
journal檔案是以“j._”開頭命名的，且是append only的，如果1個journal檔案滿了1G大小，mongodb就會新建立一個journal檔案來使用，一旦某個journal檔案所記載的寫操作都被使用過了，mongodb就會把這個journal檔案刪除。通常在journal檔案所在的資料夾下，只會存在2~3個journal檔案，除非你使用mongodb每秒都寫入大量的資料。而使用 smallfiles 這個執行時選項可以將journal檔案大小減至128M大小。
Journal的工作原理：
首先要知道在這個原理中，存在著兩個file，兩個view。兩個file是 data file 和 journal file，兩個view是 shared view 和 private view。兩個file是對磁碟而言的，而兩個view是對記憶體而言的，下面以圖解的方式解釋：
啟動服務前：
啟動服務後，MongoDB請求作業系統將Data file對映到Shared view，此時作業系統只管對映這個動作，並不將資料載入到Shared view中，而是由MongoDB在需要時再將資料進行載入到Shared view。
然後，MongoDB再請求作業系統將Shared view對映到Private view，之後MongDB對資料的讀寫操作都是直接操作的Private view：
如果發生了寫操作：
Private view變髒以後，根據journalCommitInterval的設定，將在一定時間後將寫操作往Journal file中複製，這個過程稱為“group commit”：
Journal file中記錄的是原生的操作（raw operation），這些原生的操作可以使MongoDB完成以下操作：
對文件的插入/更新（document insertion/updates）
對索引的修改（index modifications）
對名稱空間檔案的修改（changes to the namespace files）
這些原生操作告訴了Journal file資料變化發生在Data file的什麼位置。至此，MongoDB上發生的寫事件可以被認為是安全的了，因為這些寫操作已經被記錄在了Journal file上，即使伺服器掉電了，在下次啟動MongoDB時，Journal file上的寫操作將會被重演。
接下來，Journal file中記錄的寫操作會應用在Shared view上：
預設每隔60秒，MongoDB請求作業系統將Shared view重新整理輸出到Data file：
資料就被寫入到資料檔案了。這時MongoDB還會將Journal file中已輸出到Data file的寫操作刪除掉（由於MongoDB在將Journal file中寫操作放到Shared view時，是通過了一個前指標和一個後指標來操作的，所以MongoDB知道哪些寫操作是被放到Shared view了的，哪些沒有）。
最後，MongoDB還會例行地如一開始一樣，將Shared view對映到Private view，以保持一致性（也是防止Private view變得太過於髒了）。
參考：
MongoDB官方文件、
http://blog.mongodb.org/post/337 ... bs-journaling-works
journal檔案在MongoDB中的作用相當於redo日誌檔案在oracle中的作用，它可以在即使伺服器意外宕機的情況下，將資料庫操作進行重演。
在64位的機器上，2.0以上版本預設是開啟了journal的，但是在32位機器上，或者2.0以下的版本中，預設是不開啟journal的。所以在我的安裝了2.4.3版本的32位機器上，每次啟動mongodb都提示“warning: 32-bit servers don't have journaling enabled by default. Please use --journal if you want durability.”，所以我須要在啟動mongodb時帶上 --journal 引數；而在預設啟動journal的機器上如果不想啟動journal，則可以帶上 --nojournal 引數。
第一次啟動帶啟用journal的服務前，通常磁碟上是沒有journal file的，這時mongodb就會現在磁碟上為journal檔案分配磁碟空間，這個過程會花比較長的時間（所以老師的視訊演示中，第一次啟動服務時花了很長的時間），在這段時間內服務是不可用的。如果想避免這個預分配動作也是可以的，就是從別的mongodb例項中拷貝一個已經預分配的檔案，然後放到自己的journal路徑中，這個預分配檔案是不含資料的，因此是這種操作方式是安全的。另外，我在網上看到有人說如果採用ext4的檔案系統，這個預分配的時間就會減小很多（據說ext4在ext3基礎上效能的提高，比ext3在ext2基礎上效能的提高要高不少），可惜我在嘗試做這個實驗時，嘗試了幾次把虛擬機器CentOS上的ext3檔案系統轉為ext4都沒有成功，所以最終放棄了這個實驗，希望如果有人做了這個實驗的話，將過程分享分享。
預設情況下mongodb每100毫秒往journal檔案中flush一次資料，不過這是在資料檔案和journal檔案處於同一磁碟捲上的情況，而如果資料檔案和journal檔案不在同一磁碟捲上時，預設重新整理輸出時間是30毫秒。不過這個毫秒值是可以修改的，可修改範圍是2~300，值越低，重新整理輸出頻率越高，資料安全度也就越高，但磁碟效能上的開銷也更高。
journal檔案是以“j._”開頭命名的，且是append only的，如果1個journal檔案滿了1G大小，mongodb就會新建立一個journal檔案來使用，一旦某個journal檔案所記載的寫操作都被使用過了，mongodb就會把這個journal檔案刪除。通常在journal檔案所在的資料夾下，只會存在2~3個journal檔案，除非你使用mongodb每秒都寫入大量的資料。而使用 smallfiles 這個執行時選項可以將journal檔案大小減至128M大小。
Journal的工作原理：
首先要知道在這個原理中，存在著兩個file，兩個view。兩個file是 data file 和 journal file，兩個view是 shared view 和 private view。兩個file是對磁碟而言的，而兩個view是對記憶體而言的，下面以圖解的方式解釋：
啟動服務前：
啟動服務後，MongoDB請求作業系統將Data file對映到Shared view，此時作業系統只管對映這個動作，並不將資料載入到Shared view中，而是由MongoDB在需要時再將資料進行載入到Shared view。
然後，MongoDB再請求作業系統將Shared view對映到Private view，之後MongDB對資料的讀寫操作都是直接操作的Private view：
如果發生了寫操作：
Private view變髒以後，根據journalCommitInterval的設定，將在一定時間後將寫操作往Journal file中複製，這個過程稱為“group commit”：
Journal file中記錄的是原生的操作（raw operation），這些原生的操作可以使MongoDB完成以下操作：
對文件的插入/更新（document insertion/updates）
對索引的修改（index modifications）
對名稱空間檔案的修改（changes to the namespace files）
這些原生操作告訴了Journal file資料變化發生在Data file的什麼位置。至此，MongoDB上發生的寫事件可以被認為是安全的了，因為這些寫操作已經被記錄在了Journal file上，即使伺服器掉電了，在下次啟動MongoDB時，Journal file上的寫操作將會被重演。
接下來，Journal file中記錄的寫操作會應用在Shared view上：
預設每隔60秒，MongoDB請求作業系統將Shared view重新整理輸出到Data file：
資料就被寫入到資料檔案了。這時MongoDB還會將Journal file中已輸出到Data file的寫操作刪除掉（由於MongoDB在將Journal file中寫操作放到Shared view時，是通過了一個前指標和一個後指標來操作的，所以MongoDB知道哪些寫操作是被放到Shared view了的，哪些沒有）。
最後，MongoDB還會例行地如一開始一樣，將Shared view對映到Private view，以保持一致性（也是防止Private view變得太過於髒了）。
參考：
MongoDB官方文件、
http://blog.mongodb.org/post/337 ... bs-journaling-works