前言

成都創(chuàng)新互聯(lián)從2013年成立，先為長(zhǎng)陽等服務(wù)建站，長(zhǎng)陽等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為長(zhǎng)陽企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

任何一種數(shù)據(jù)庫(kù)都有各種各樣的日志，MongoDB也不例外。MongoDB中有4種日志，分別是系統(tǒng)日志、Journal日志、oplog主從日志、慢查詢?nèi)罩镜取＿@些日志記錄著MongoDB數(shù)據(jù)庫(kù)不同方面的蹤跡。下面分別介紹這幾種日志。

系統(tǒng)日志

系統(tǒng)日志在MongoDB數(shù)據(jù)庫(kù)中很重要，它記錄著MongoDB啟動(dòng)和停止的操作，以及服務(wù)器在運(yùn)行過程中發(fā)生的任何異常信息。
配置系統(tǒng)日志的方法比較簡(jiǎn)單，在啟動(dòng)mongod時(shí)指定logpath參數(shù)即可

mongod -logpath=/data/log/mongodb/serverlog.log -logappend

系統(tǒng)日志會(huì)向logpath指定的文件持續(xù)追加。

Journal日志

journaling(日記) 日志功能則是 MongoDB 里面非常重要的一個(gè)功能 ， 它保證了數(shù)據(jù)庫(kù)服務(wù)器在意外斷電 、 自然災(zāi)害等情況下數(shù)據(jù)的完整性。它通過預(yù)寫式的redo日志為MongoDB增加了額外的可靠性保障。開啟該功能時(shí),MongoDB會(huì)在進(jìn)行寫入時(shí)建立一條Journal日志,其中包含了此次寫入操作具體更改的磁盤地址和字節(jié)。因此一旦服務(wù)器突然停機(jī)，可在啟動(dòng)時(shí)對(duì)日記進(jìn)行重放，從而重新執(zhí)行那些停機(jī)前沒能夠刷新到磁盤的寫入操作。

MongoDB配置WiredTiger引擎使用內(nèi)存緩沖區(qū)來保存journal記錄,WiredTiger根據(jù)以下間隔或條件將緩沖的日志記錄同步到磁盤

1. 從MongoDB 3.2版本開始每隔50ms將緩沖的journal數(shù)據(jù)同步到磁盤
2. 如果寫入操作設(shè)置了j:true，則WiredTiger強(qiáng)制同步日志文件
3. 由于MongoDB使用的journal文件大小限制為100MB,因此WiredTiger大約每100MB數(shù)據(jù)創(chuàng)建一個(gè)新的日志文件。當(dāng)WiredTiger創(chuàng)建新的journal文件時(shí)，WiredTiger會(huì)同步以前journal文件

MongoDB達(dá)到上面的提交，便會(huì)將更新操作寫入日志。這意味著MongoDB會(huì)批量地提交更改，即每次寫入不會(huì)立即刷新到磁盤。不過在默認(rèn)設(shè)置下，系統(tǒng)發(fā)生崩潰時(shí)，不可能丟失超過50ms的寫入數(shù)據(jù)。

數(shù)據(jù)文件默認(rèn)每60秒刷新到磁盤一次，因此Journal文件只需記錄約60s的寫入數(shù)據(jù)。日志系統(tǒng)為此預(yù)先分配了若干個(gè)空文件，這些文件存放在/data/db/journal目錄中，目錄名為_j.0、_j.1等

長(zhǎng)時(shí)間運(yùn)行MongoDB后，日志目錄中會(huì)出現(xiàn)類似_j.6217、_j.6218的文件，這些是當(dāng)前的日志文件，文件中的數(shù)值會(huì)隨著MongoDB運(yùn)行時(shí)間的增長(zhǎng)而增大。數(shù)據(jù)庫(kù)正常關(guān)閉后，日記文件會(huì)被清除(因?yàn)檎ｊP(guān)閉后就不在需要這些文件了).

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

如發(fā)生系統(tǒng)崩潰或使用kill -9命令強(qiáng)制終止數(shù)據(jù)庫(kù)的運(yùn)行，mongod會(huì)在啟動(dòng)時(shí)重放journal文件，同時(shí)會(huì)顯示出大量的校驗(yàn)信息。

上面說的都是針對(duì)WiredTiger引擎,對(duì)于MMAPv1引擎來說有一點(diǎn)不一樣，首先它是每100ms進(jìn)行刷盤，其次它是通過private view寫入journal文件,通過shared view寫入數(shù)據(jù)文件。這里就不過多講解了，因?yàn)镸ongoDB 4.0已經(jīng)不推薦使用這個(gè)存儲(chǔ)引擎了。

從MongoDB 3.2版本開始WiredTiger是MongoDB推薦的默認(rèn)存儲(chǔ)引擎

需要注意的是如果客戶端的寫入速度超過了日記的刷新速度，mongod則會(huì)限制寫入操作，直到日記完成磁盤的寫入。這是mongod會(huì)限制寫入的唯一情況。

固定集合(Capped Collection)

在講下面兩種日志之前先來認(rèn)識(shí)下capped collection。

MongoDB中的普通集合是動(dòng)態(tài)創(chuàng)建的，而且可以自動(dòng)增長(zhǎng)以容納更多的數(shù)據(jù)。MongoDB中還有另一種不同類型的集合，叫做固定集合。固定集合需要事先創(chuàng)建好，而且它的大小是固定的。固定集合的行為類型與循環(huán)隊(duì)列一樣。如果沒有空間了，最老的文檔會(huì)被刪除以釋放空間，新插入的文檔會(huì)占據(jù)這塊空間。

創(chuàng)建固定集合：

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

創(chuàng)建了一個(gè)大小為100000字節(jié)的固定大小集合,文檔數(shù)量為100.不管先到達(dá)哪個(gè)限制，之后插入的新文檔就會(huì)把最老的文檔擠出集合：固定集合的文檔數(shù)量不能超過文檔數(shù)量限制，也不能超過大小限制。

固定集合創(chuàng)建之后就不能改變,無法將固定集合轉(zhuǎn)換為非固定集合,但是可以將常規(guī)集合轉(zhuǎn)換為固定集合。

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

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

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

oplog主從日志

Replica Sets復(fù)制集用于在多臺(tái)服務(wù)器之間備份數(shù)據(jù)。MongoDB的復(fù)制功能是使用操作日志oplog實(shí)現(xiàn)的，操作日志包含了主節(jié)點(diǎn)的每一次寫操作。oplog是主節(jié)點(diǎn)的local數(shù)據(jù)庫(kù)中的一個(gè)固定集合。備份節(jié)點(diǎn)通過查詢這個(gè)集合就可以知道需要進(jìn)行復(fù)制的操作。

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

每個(gè)備份節(jié)點(diǎn)都維護(hù)著自己的oplog,記錄著每一次從主節(jié)點(diǎn)復(fù)制數(shù)據(jù)的操作。這樣，每個(gè)成員都可以作為同步源給其他成員使用。

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

oplog中按順序保存著所有執(zhí)行過的寫操作，replica sets中每個(gè)成員都維護(hù)者一份自己的oplog，每個(gè)成員的oplog都應(yīng)該跟主節(jié)點(diǎn)的oplog完全一致(可能會(huì)有一些延遲)

如果某個(gè)備份節(jié)點(diǎn)由于某些原因掛了，但它重新啟動(dòng)后，就會(huì)自動(dòng)從oplog中最后一個(gè)操作開始進(jìn)行同步。由于復(fù)制操作的過程是想復(fù)制數(shù)據(jù)在寫入oplog,所以備份節(jié)點(diǎn)可能會(huì)在已經(jīng)同步過的數(shù)據(jù)上再次執(zhí)行復(fù)制操作。MongoDB在設(shè)計(jì)之初就考慮到了這種情況:將oplog中的同一個(gè)操作執(zhí)行多次，與只執(zhí)行一次的效果是一樣的。

由于oplog大小是固定的，它只能保持特定數(shù)量的操作日志。通常，oplog使用空間的增長(zhǎng)速度與系統(tǒng)處理寫請(qǐng)求的速率幾乎相同：如果主節(jié)點(diǎn)上每分鐘處理了1KB的寫入請(qǐng)求，那么oplog很可能也會(huì)在一分鐘內(nèi)寫入1KB條操作日志。

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

慢查詢?nèi)罩?/strong>

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

默認(rèn)情況下，系統(tǒng)分析器處于關(guān)閉狀態(tài)，不會(huì)進(jìn)行任何記錄?？梢栽趕hell中運(yùn)行db.setProfilingLevel()開啟分析器

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

第一個(gè)參數(shù)是指定級(jí)別，不同的級(jí)別代表不同的意義，0表示關(guān)閉，1表示默認(rèn)記錄耗時(shí)大于100毫秒的操作，2表示記錄所有操作。第二個(gè)參數(shù)則是自定義“耗時(shí)過長(zhǎng)"標(biāo)準(zhǔn)，比如記錄所有耗時(shí)操作500ms的操作

db.setProfilingLevel(1,500);

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

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

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)創(chuàng)新互聯(lián)的支持。