共計 3852 個字符，預計需要花費 10 分鐘才能閱讀完成。

前言

任何一種數據庫都有各種各樣的日志，MongoDB 也不例外。MongoDB 中有 4 種日志，分別是系統日志、Journal 日志、oplog 主從日志、慢查詢日志等。這些日志記錄著 MongoDB 數據庫不同方面的蹤跡。下面分別介紹這幾種日志。

系統日志

系統日志在 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 中還有另一種不同類型的集合，叫做固定集合。固定集合需要事先創建好，而且它的大小是固定的。固定集合的行為類型與循環隊列一樣。如果沒有空間了，最老的文檔會被刪除以釋放空間，新插入的文檔會占據這塊空間。

創建固定集合：

db.createCollection("collectionName",{"capped":true, "size":100000, "max":100})

創建了一個大小為 100000 字節的固定大小集合, 文檔數量為 100. 不管先到達哪個限制，之后插入的新文檔就會把最老的文檔擠出集合：固定集合的文檔數量不能超過文檔數量限制，也不能超過大小限制。

固定集合創建之后就不能改變, 無法將固定集合轉換為非固定集合, 但是可以將常規集合轉換為固定集合。

db.runCommand({"convertToCapped": "test", "size" : 10000});

固定集合可以進行一種特殊的排序，稱為自然排序(natural sort), 自然排序返回結果集中文檔的順序就是文檔在磁盤的順序。自然順序就是文檔的插入順序，因此自然排序得到的文檔是從舊到新排列的。當然也可以按照從新到舊：

db.my_capped_collection.find().sort({"$natural": -1});

oplog 主從日志

Replica Sets 復制集用于在多臺服務器之間備份數據。MongoDB 的復制功能是使用操作日志 oplog 實現的，操作日志包含了主節點的每一次寫操作。oplog 是主節點的 local 數據庫中的一個固定集合。備份節點通過查詢這個集合就可以知道需要進行復制的操作。

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

每個備份節點都維護著自己的 oplog, 記錄著每一次從主節點復制數據的操作。這樣，每個成員都可以作為同步源給其他成員使用。

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

oplog 中按順序保存著所有執行過的寫操作，replica sets 中每個成員都維護者一份自己的 oplog，每個成員的 oplog 都應該跟主節點的 oplog 完全一致(可能會有一些延遲)

如果某個備份節點由于某些原因掛了，但它重新啟動后，就會自動從 oplog 中最后一個操作開始進行同步。由于復制操作的過程是想復制數據在寫入 oplog, 所以備份節點可能會在已經同步過的數據上再次執行復制操作。MongoDB 在設計之初就考慮到了這種情況: 將 oplog 中的同一個操作執行多次，與只執行一次的效果是一樣的。

由于 oplog 大小是固定的，它只能保持特定數量的操作日志。通常，oplog 使用空間的增長速度與系統處理寫請求的速率幾乎相同：如果主節點上每分鐘處理了 1KB 的寫入請求，那么 oplog 很可能也會在一分鐘內寫入 1KB 條操作日志。

但是，有一些例外：如果單次請求能夠影響到多個文檔 (比如刪除多個文檔或者多文檔更新),oplog 中就會出現多條操作日志。如果單個操作會影響多個文檔，那么每個受影響的文檔都會對應 oplog 的一條日志。因此，如果執行 db.student.remove() 刪除了 10w 個文檔，那么 oplog 中也就會有 10w 條操作日志，每個日志對應一個被刪除的文檔。如果執行大量的批量操作，oplog 很快就會被填滿。

慢查詢日志

MongoDB 中使用系統分析器 (system profiler) 來查找耗時過長的操作。系統分析器記錄固定集合 system.profile 中的操作，并提供大量有關耗時過長的操作信息，但相應的 mongod 的整體性能也會有所下降。因此我們一般定期打開分析器來獲取信息。

默認情況下，系統分析器處于關閉狀態，不會進行任何記錄。可以在 shell 中運行 db.setProfilingLevel()開啟分析器

db.setProfilingLevel(level, slowms) 0=off 1=slow 2=all

第一個參數是指定級別，不同的級別代表不同的意義，0 表示關閉，1 表示默認記錄耗時大于 100 毫秒的操作，2 表示記錄所有操作。第二個參數則是自定義“耗時過長 ” 標準，比如記錄所有耗時操作 500ms 的操作

db.setProfilingLevel(1,500);

如果開啟了分析器而 system.profile 集合并不存在，MongoDB 會為其建立一個大小為若干 MB 的固定集合(capped collection)。如希望分析器運行更長時間，可能需要更大的空間記錄更多的操作。此時可以關閉分析器，刪除并重新建立一個新的名為 system.profile 的固定集合，并令其容量符合要求。然后在數據庫上重新啟用分析器。

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

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對丸趣 TV 的支持。

向 AI 問一下細節

丸趣 TV 網 – 提供最優質的資源集合！