mongodb日志包括哪些，你知道多少？

2024-09-07 00:22:36

字體：大中小

來源：轉載

供稿：網友

這篇文章主要給大家介紹MongoDB的日志，關于MongoDB日志，有四種，分別是系統日志、Journal日志、oplog主從日志、慢查詢日志。那么它們的用處都是什么呢？

       系統日志
       系統日志在MongoDB數據庫中很重要，它記錄著MongoDB啟動和停止的操作，以及服務器在運行過程中發生的任何異常信息。配置系統日志的方法比較簡單，在啟動mongod時指定logpath參數即可
mongod -logpath=/data/log/mongodb/serverlog.log -logappend
       系統日志會向logpath指定的文件持續追加。
       Journal日志
       journaling(日記) 日志功能則是 MongoDB 里面非常重要的一個功能，它保證了數據庫服務器在意外斷電、自然災害等情況下數據的完整性。它通過預寫式的redo日志為MongoDB增加了額外的可靠性保障。開啟該功能時,MongoDB會在進行寫入時建立一條Journal日志,其中包含了此次寫入操作具體更改的磁盤地址和字節。因此一旦服務器突然停機，可在啟動時對日記進行重放，從而重新執行那些停機前沒能夠刷新到磁盤的寫入操作。
       MongoDB配置WiredTiger引擎使用內存緩沖區來保存journal記錄,WiredTiger根據以下間隔或條件將緩沖的日志記錄同步到磁盤

從MongoDB 3.2版本開始每隔50ms將緩沖的journal數據同步到磁盤
如果寫入操作設置了j:true，則WiredTiger強制同步日志文件
由于MongoDB使用的journal文件大小限制為100MB,因此WiredTiger大約每100MB數據創建一個新的日志文件。當WiredTiger創建新的journal文件時，WiredTiger會同步以前journal文件
       MongoDB達到上面的提交，便會將更新操作寫入日志。這意味著MongoDB會批量地提交更改，即每次寫入不會立即刷新到磁盤。不過在默認設置下，系統發生崩潰時，不可能丟失超過50ms的寫入數據。
       數據文件默認每60秒刷新到磁盤一次，因此Journal文件只需記錄約60s的寫入數據。日志系統為此預先分配了若干個空文件，這些文件存放在/data/db/journal目錄中，目錄名為_j.0、_j.1等
       長時間運行MongoDB后，日志目錄中會出現類似_j.6217、_j.6218的文件，這些是當前的日志文件，文件中的數值會隨著MongoDB運行時間的增長而增大。數據庫正常關閉后，日記文件會被清除(因為正常關閉后就不在需要這些文件了).

向mongodb中寫入數據是先寫入內存，然后每隔60s在刷盤，同樣寫入journal,也是先寫入對應的buffer，然后每隔50ms在刷盤到磁盤的journal文件
使用WiredTiger，即使沒有journal功能，MongoDB也可以從最后一個檢查點(checkpoint,可以想成鏡像)恢復;但是，要恢復在上一個檢查點之后所做的更改，還是需要使用Journal

       如發生系統崩潰或使用kill -9命令強制終止數據庫的運行，mongod會在啟動時重放journal文件，同時會顯示出大量的校驗信息。

上面說的都是針對WiredTiger引擎,對于MMAPv1引擎來說有一點不一樣，首先它是每100ms進行刷盤，其次它是通過private view寫入journal文件,通過shared view寫入數據文件。這里就不過多講解了，因為MongoDB 4.0已經不推薦使用這個存儲引擎了。
從MongoDB 3.2版本開始WiredTiger是MongoDB推薦的默認存儲引擎

       需要注意的是如果客戶端的寫入速度超過了日記的刷新速度，mongod則會限制寫入操作，直到日記完成磁盤的寫入。這是mongod會限制寫入的唯一情況。
       固定集合(Capped Collection)
       在講下面兩種日志之前先來認識下capped collection。
       MongoDB中的普通集合是動態創建的，而且可以自動增長以容納更多的數據。MongoDB中還有另一種不同類型的集合，叫做固定集合。固定集合需要事先創建好，而且它的大小是固定的。固定集合的行為類型與循環隊列一樣。如果沒有空間了，最老的文檔會被刪除以釋放空間，新插入的文檔會占據這塊空間。

一個mongod實例中的所有數據庫都使用同一個oplog，也就是所有數據庫的操作日志(插入，刪除，修改)都會記錄到oplog中

       每個備份節點都維護著自己的oplog,記錄著每一次從主節點復制數據的操作。這樣，每個成員都可以作為同步源給其他成員使用。
       如圖所示，備份節點從當前使用的同步源中獲取需要執行的操作，然后在自己的數據集上執行這些操作，最后再將這些操作寫入自己的oplog,如果遇到某個操作失敗的情況(只有當同步源的數據損壞或者數據與主節點不一致時才可能發生),那么備份節點就會停止從當前的同步源復制數據。

       oplog中按順序保存著所有執行過的寫操作，replica sets中每個成員都維護者一份自己的oplog，每個成員的oplog都應該跟主節點的oplog完全一致(可能會有一些延遲)
       如果某個備份節點由于某些原因掛了，但它重新啟動后，就會自動從oplog中最后一個操作開始進行同步。由于復制操作的過程是想復制數據在寫入oplog,所以備份節點可能會在已經同步過的數據上再次執行復制操作。MongoDB在設計之初就考慮到了這種情況:將oplog中的同一個操作執行多次，與只執行一次的效果是一樣的。
       由于oplog大小是固定的，它只能保持特定數量的操作日志。通常，oplog使用空間的增長速度與系統處理寫請求的速率幾乎相同：如果主節點上每分鐘處理了1KB的寫入請求，那么oplog很可能也會在一分鐘內寫入1KB條操作日志。
        如果開啟了分析器而system.profile集合并不存在，MongoDB會為其建立一個大小為若干MB的固定集合(capped collection)。如希望分析器運行更長時間，可能需要更大的空間記錄更多的操作。此時可以關閉分析器，刪除并重新建立一個新的名為system.profile的固定集合，并令其容量符合要求。然后在數據庫上重新啟用分析器。

可以通過db.system.profile.stats()查看集合的最大容量.

（編輯：武林網）

上一篇：MongoDB中mongoexport工具的用處是什么？如何使用？

下一篇：MongoDB通配符索引如何用？