MongoDB 中有幾種日志?
MongoDB 中有 4 種日志，分別是系統日志、Journal 日志、oplog 主從日志、慢查詢日志等。這些日志記錄着 MongoDB 數據庫不同方面的蹤跡。
系統日志
系統日志在 MongoDB 數據庫中很重要，它記錄着 MongoDB 啟動和停止的操作，以及服務器在運行過程中發生的任何異常信息。
配置系統日志的方法比較簡單，在啟動 mongod 時指定 logpath 參數即可
```shell
mongod -logpath=/data/log/mongodb/serverlog.log -logappend
```
系統日志會向 logpath 指定的文件持續追加。
日志等。這些日志記錄着 MongoDB 數據庫不同方面的蹤跡。
Journal 日志
journaling(日記) 日志功能則是 MongoDB 里面非常重要的一個功能 ， 它保證了數據庫服務器在意外斷電 、 自然災害等情況下數據的完整性。它通過預寫式的 redo 日志為 MongoDB 增加了額外的可靠性保障。開啟該功能時, MongoDB 會在進行寫入時建立一條 Journal 日志, 其中包含了此次寫入操作具體更改的磁盤地址和字節。因此一旦服務器突然停機，可在啟動時對日記進行重放，從而重新執行那些停機前沒能夠刷新到磁盤的寫入操作。
MongoDB 配置 WiredTiger 引擎使用內存緩沖區來保存 journal 記錄, WiredTiger 根據以下間隔或條件將緩沖的日志記錄同步到磁盤
日志等。這些日志記錄着 MongoDB 數據庫不同方面的蹤跡。
固定集合 (Capped Collection)
MongoDB 中的普通集合是動態創建的，而且可以自動增長以容納更多的數據。MongoDB 中還有另一種不同類型的集合，叫做固定集合。固定集合需要事先創建好，而且它的大小是固定的。固定集合的行為類型與循環隊列一樣。如果沒有空間了，最老的文檔會被刪除以釋放空間，新插入的文檔會占據這塊空間。
oplog 主從日志
Replica Sets 復制集用於在多台服務器之間備份數據。MongoDB 的復制功能是使用操作日志 oplog 實現的，操作日志包含了主節點的每一次寫操作。oplog 是主節點的 local 數據庫中的一個固定集合。備份節點通過查詢這個集合就可以知道需要進行復制的操作。
一個 mongod 實例中的所有數據庫都使用同一個 oplog，也就是所有數據庫的操作日志 (插入，刪除，修改) 都會記錄到 oplog 中
MongoDB oplog 詳解
oplog 簡介
oplog 是 local 庫下的一個固定集合，Secondary 就是通過查看 Primary 的 oplog 這個集合來進行復制的。每個節點都有 oplog，記錄這從主節點復制過來的信息，這樣每個成員都可以作為同步源給其他節點。
Oplog 可以說是 Mongodb Replication 的紐帶了。
副本集數據同步的過程
副本集中數據同步的詳細過程：Primary 節點寫入數據，Secondary 通過讀取 Primary 的 oplog 得到復制信息，開始復制數據並且將復制信息寫入到自己的 oplog。如果某個操作失敗（只有當同步源的數據損壞或者數據與主節點不一致時才可能發生），則備份節點停止從當前數據源復制數據。如果某個備份節點由於某些原因掛掉了，當重新啟動后，就會自動從 oplog 的最后一個操作開始同步，同步完成后，將信息寫入自己的 oplog，由於復制操作是先復制數據，復制完成后再寫入 oplog，有可能相同的操作會同步兩份，不過 MongoDB 在設計之初就考慮到這個問題，將 oplog 的同一個操作執行多次，與執行一次的效果是一樣的。
- 作用：
當 Primary 進行寫操作的時候，會將這些寫操作記錄寫入 Primary 的 Oplog 中，而后 Secondary 會將 Oplog 復制到本機並應用這些操作，從而實現 Replication 的功能。
同時由於其記錄了 Primary 上的寫操作，故還能將其用作數據恢復。
可以簡單的將其視作 Mysql 中的 binlog。
oplog 的增長速度
oplog 是固定大小，他只能保存特定數量的操作日志，通常 oplog 使用空間的增長速度跟系統處理寫請求的速度相當，如果主節點上每分鍾處理 1KB 的寫入數據，那么 oplog 每分鍾大約也寫入 1KB 數據。如果單次操作影響到了多個文檔（比如刪除了多個文檔或者更新了多個文檔）則 oplog 可能就會有多條操作日志。db.testcoll.remove() 刪除了 1000000 個文檔，那么 oplog 中就會有 1000000 條操作日志。如果存在大批量的操作，oplog 有可能很快就會被寫滿了。
- 大小：
Oplog 是一個 capped collection。
在 64 位的 Linux, Solaris, FreeBSD, and Windows 系統中，Mongodb 默認將其大小設置為可用 disk 空間的 5%（默認最小為 1G，最大為 50G），或也可以在 mongodb 復制集實例初始化之前將 mongo.conf 中 oplogSize 設置為我們需要的值。
local.oplog.rs 一個 capped collection 集合. 可在命令行下使用 --oplogSize 選項設置該集合大小尺寸.
但是由於 Oplog 其保證了復制的正常進行，以及數據的安全性和容災能力。
oplog 注意事項：
local.oplog.rs 特殊的集合。用來記錄 Primary 節點的操作。
為了提高復制的效率，復制集中的所有節點之間會相互的心跳檢測（ping）。每個節點都可以從其他節點上獲取 oplog。
oplog 中的一條操作。不管執行多少次效果是一樣的
oplog 的大小
第一次啟動復制集中的節點時，MongoDB 會建立 Oplog, 會有一個默認的大小，這個大小取決於機器的操作系統
- rs.printReplicationInfo() 查看 oplog 的狀態，輸出信息包括 oplog 日志大小，操作日志記錄的起始時間。
- db.getReplicationInfo() 可以用來查看 oplog 的狀態、大小、存儲的時間范圍。
oplog 數據結構
通過下面的命令取出一條 oplog：
shell db.oplog.rs.find().skip(1).limit(1).toArray()
rs0:PRIMARY> db.oplog.rs.find().skip(1).limit(1).toArray()
[
{
"ts" : Timestamp(1586243552, 3),
"t" : NumberLong(1),
"h" : NumberLong(0),
"v" : 2,
"op" : "c",
"ns" : "config.$cmd",
"ui" : UUID("4781aa3b-e371-4a96-a6f5-f59fac22ce06"),
"wall" : ISODate("2020-04-07T07:12:32.943Z"),
"o" : {
"create" : "transactions",
"idIndex" : {
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "config.transactions"
}
}
}
]
- ts: 8 字節的時間戳，由 4 字節 unix timestamp + 4 字節自增計數表示。這個值很重要，在選舉 (如 master 宕機時) 新 primary 時，會選擇 ts 最大的那個 secondary 作為新 primary
- op：1 字節的操作類型
"i"： insert
"u"： update
"d"： delete
"c"： db cmd
"db"：聲明當前數據庫 (其中 ns 被設置成為 => 數據庫名稱 + '.')
"n": no op, 即空操作，其會定期執行以確保時效性 - ns：操作所在的 namespace
- o：操作所對應的 document，即當前操作的內容（比如更新操作時要更新的的字段 和值）
- o2: 在執行更新操作時的 where 條件，僅限於 update 時才有該屬性
- 查看 oplog 的信息,通過 "db.printReplicationInfo()" 命令可以查看 oplog 的信息
- 字段說明：
configured oplog size： oplog 文件大小
log length start to end: oplog 日志的啟用時間段
oplog first event time: 第一個事務日志的產生時間
oplog last event time: 最后一個事務日志的產生時間
now: 現在的時間
MongoDB server version: 4.2.5
rs0:PRIMARY> db.getReplicationInfo()
{
"logSizeMB" : 2270.184814453125,
"usedMB" : 474.85,
"timeDiff" : 4147617,
"timeDiffHours" : 1152.12,
"tFirst" : "Tue Apr 07 2020 15:12:32 GMT+0800 (CST)",
"tLast" : "Mon May 25 2020 15:19:29 GMT+0800 (CST)",
"now" : "Mon May 25 2020 15:42:03 GMT+0800 (CST)"
}
rs0:PRIMARY> db.printReplicationInfo()
configured oplog size: 2270.184814453125MB
log length start to end: 4147757secs (1152.15hrs)
oplog first event time: Tue Apr 07 2020 15:12:32 GMT+0800 (CST)
oplog last event time: Mon May 25 2020 15:21:49 GMT+0800 (CST)
now: Mon May 25 2020 15:44:27 GMT+0800 (CST)
Monstache同步MongoDB到ElasticSearch注意事項
注意，mongodb通過monstache同步到elasticsearch小心查看日志文件（必須輸出日志），如果有錯誤即使不影響同步結果，也要解決，可能或導致mongo產生錯誤日志，導致日志暴增，致使服務掛掉
mongodb注意
- 如果mongo開啟了安全認證，需要給monstache同步用的用戶一個root權限,以使這個用戶可以訪問admin和local數據庫（這里用的比較暴力的辦法，我測試通過給只需要同步的數據庫用戶添加admin、local數據庫讀寫權限，還是繼續報錯，只能采取了下下策）
monstache配置注意
- monstache同步配置中要配置enable-oplog：true（默認為change-steam，默認方式理論上）
- 下面是local數據庫表
rs0:PRIMARY> use local switched to db local rs0:PRIMARY> show tables oplog.rs # monstache要訪問這個表，需要monstache配置為enable-oplog：ture replset.election replset.minvalid replset.oplogTruncateAfterPoint startup_log
MongoDB日志暴增另一種解決方式（治標不治本）
- 登入數據庫
db.adminCommand( { logRotate : 1 } )
- 使用系統默認的日志輪轉機制存儲和輪轉日志輸出
kill -SIGUSR1 <mongod process id>
參考
官方文檔