mongodb oplog詳解和格式分析

1. 基本概念

    oplog使用固定大小集合記錄了數據庫中全部修改操做的操做日誌(新增、修改和刪除，無查詢)，mongodb收到修改請求後，先在主節點（Primary）執行請求，再把操做日誌保存到oplog表中，其餘從節點（Secondary）到主節點拉取oplog並在異步進程中應用這些操做，從而達到主從數據的一致性。複製組內的全部節點都會保存一份oplog(集合名local.oplog.rs)，這讓他們能夠保持一樣的數據庫狀態。

    爲了提升同步效率，全部複製組成員都會向其餘成員發送保活報文(pings)，任意從節點能夠從其餘成員節點同步oplog（便可以從主節點同步，也能夠從從節點同步）。oplog中的操做都是冪等的，即oplog中的某個操做日誌在目標數據庫中應用一次或者屢次，其結果都是同樣的。

    主從同步示意圖以下(客戶端寫數據到主節點，從節點從主節點同步oplog並應用到本節點)：

 

2. Oplog 的默認儲存大小

 當你首次啓動複製組節點時，在你未指定oplog大小時，mongodb會使用默認大小來建立oplog。

對於Unix和Windows系統來講，默認大小和存儲引擎的對應關係以下：

存儲引擎類型	oplog大小	下限	上限
內存	物理內存的5%	50MB	50GB
WiredTiger	空閒磁盤的5%	990MB	50GB

 (注意，最新4.4版本的mongodb移除了MMAP類型存儲引擎的支持。)

對於64位maxOS系統來講，參照使用的存儲引擎類型，該默認大小是192MB（物理內存或者磁盤空間），以下：

存儲引擎類型	oplog大小
內存	192MB物理內存
WiredTiger	192MB的磁盤空間

 大部分狀況下，oplog的默認大小是足夠的。舉個例子，若是5%的磁盤空間存儲了最近24小時的操做日誌，此時若是某個從節點的日誌同步時間差超過24小時時，從節點將中止同步oplog，並將自身的狀態從「Secondery」切換到「STALE」。固然，在實際的運行環境中，大部分複製組成員的負載會低一些，他們的oplog中也會持有更長時間段的日誌。

3. 可能須要更大oplog的工做負載

若是你預測到你的複製組的工做負載屬於如下的模式，你須要建立比默認值更大一些的oplog。相反的，若是你的應用大部分狀況下是讀操做，只有小部分的寫操做，那麼更小一些的oplog也是知足須要的。

下面的工做負載可能須要更大一些的oplog

單次操做會更新多條記錄

爲了知足oplog的冪等性，單次操做更新多條記錄時，mongodb會記錄多條操做日誌到oplog中，這種場景就須要使用大量的oplog的空間，雖然此時數據大小或者磁盤大小並無相應的增長那麼多。

刪除操做和插入操做同樣多時

 若是你的刪除操做請求量和插入操做的請求量大體至關時，數據庫在磁盤空間消耗方面不會有明顯增加，可是操做日誌的大小會很是巨大。

顯著數量的原文檔更新

若是工做負載的大部分操做都是原文檔更新，此時雖然不會增長數據庫中文檔的數量，可是數據庫須要記錄大量的操做日誌。

4. Oplog狀態

若是要查看oplog的狀態，包含記錄條數和時間範圍，能夠使用"rs.printReplicationInfo() "命令，以下：

MongoDB Enterprise repa:PRIMARY> rs.printReplicationInfo()
configured oplog size:   1024MB  // oplog大小是1024MB
log length start to end: 867353secs (240.93hrs)  // 第一條和最後一條日誌的時間差是240.93小時
oplog first event time:  Wed Jul 07 2021 20:24:57 GMT+0800
oplog last event time:   Sat Jul 17 2021 21:20:50 GMT+0800
now:                     Sat Jul 17 2021 21:20:56 GMT+0800

 

5. Oplog格式

從前面知道oplog是存儲在數據庫local中，表名爲「oplog.rs」，經過查詢命令看一下oplog的數據格式：

db.oplog.rs.find({"ns":"test.users"}).limit(1)   // ns字段指明查詢對數據庫test中users表的操做日誌
{
    "ts": Timestamp(1625660877, 2),     // 日誌的操做時間戳，第一個數字是時間戳，單位秒，第二個數字是當前秒的第2個操做
    "t": NumberLong(2),
    "h": NumberLong("5521980394145765083"),
    "v": 2,
    "op": "i",            // i表示insert，u表示update,d表示delete，c 表示的是數據庫的命令，好比建表,n表示noop,即空操做
    "ns": "test.users",   // 命名空間，即數據庫和集合名稱
    "ui": UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"), // 鏈接到mongodb的客戶端會話id
    "wall": ISODate("2021-07-07T12:27:57.689Z"),  // 操做執行時間，utc時間
    "o": {        // 操做的內容，對於不一樣的op類型，其格式不盡相同
        "_id": ObjectId("60e59dcd46db1fb4605f8b18"),
        "name": "1"
    }
}

 

6. CUD操做和Oplog的對應關係

前面分析oplog日誌格式的時候，查看了一條insert操做對應的日誌，就再也不贅述，下面再看下delete和update對應的日誌格式(find不會產生oplog)。

delete操做

首先插入三條記錄：

MongoDB Enterprise repa:PRIMARY> use test
switched to db test
MongoDB Enterprise repa:PRIMARY> db.users.insert({"name":"張三","age":NumberInt(10),"sex":"男"})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise repa:PRIMARY> db.users.insert({"name":"李四","age":NumberInt(11),"sex":"男"})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise repa:PRIMARY> db.users.insert({"name":"王五","age":NumberInt(12),"sex":"男"})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise repa:PRIMARY> db.users.find()
{ "_id" : ObjectId("60f2e11b0d98dc3b374199de"), "name" : "張三", "age" : 10, "sex" : "男" }
{ "_id" : ObjectId("60f2e11e0d98dc3b374199df"), "name" : "李四", "age" : 11, "sex" : "男" }
{ "_id" : ObjectId("60f2e11e0d98dc3b374199e0"), "name" : "王五", "age" : 12, "sex" : "男" }

執行delete操做，匹配條件是{"sex":"男"}，即刪除全部性別爲男的記錄：

MongoDB Enterprise repa:PRIMARY> db.users.remove({"sex":"男"})
WriteResult({ "nRemoved" : 3 })
MongoDB Enterprise repa:PRIMARY> db.users.find()
MongoDB Enterprise repa:PRIMARY>

能夠看到，一條刪除命令刪除了三條記錄，對應的oplog是什麼呢，來，查一下：

MongoDB Enterprise repa:PRIMARY> use local
switched to db local
MongoDB Enterprise repa:PRIMARY> db.oplog.rs.find({"ns":"test.users","op":"d","wall":{"$gt":ISODate("2021-07-17T13:50:57.689Z")}})
{ "ts" : Timestamp(1626530154, 1), "t" : NumberLong(2), "h" : NumberLong("5834731856459959506"), "v" : 2, "op" : "d", "ns" : "test.users", "ui" : UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"), "wall" : ISODate("2021-07-17T13:55:54.424Z"), "o" : { "_id" : ObjectId("60f2e11b0d98dc3b374199de") } }
{ "ts" : Timestamp(1626530154, 2), "t" : NumberLong(2), "h" : NumberLong("-2164276082472824844"), "v" : 2, "op" : "d", "ns" : "test.users", "ui" : UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"), "wall" : ISODate("2021-07-17T13:55:54.424Z"), "o" : { "_id" : ObjectId("60f2e11e0d98dc3b374199df") } }
{ "ts" : Timestamp(1626530154, 3), "t" : NumberLong(2), "h" : NumberLong("3834858247238363179"), "v" : 2, "op" : "d", "ns" : "test.users", "ui" : UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"), "wall" : ISODate("2021-07-17T13:55:54.424Z"), "o" : { "_id" : ObjectId("60f2e11e0d98dc3b374199e0") } }
MongoDB Enterprise repa:PRIMARY>

從上能夠看到，一條刪除命令，在oplog中記錄了三條日誌，下面分析其中的一條：

{
    "ts": Timestamp(1626530154, 1),
    "t": NumberLong(2),
    "h": NumberLong("5834731856459959506"),
    "v": 2,
    "op": "d",   // 刪除操做
    "ns": "test.users",  // 數據庫是test，集合是users
    "ui": UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"),
    "wall": ISODate("2021-07-17T13:55:54.424Z"),
    "o": {     // 待刪除記錄的_id
        "_id": ObjectId("60f2e11b0d98dc3b374199de")
    }
}

從上面日誌分析能夠獲得結論：

用戶的一次刪除請求，若是刪除了N條記錄，那麼oplog中將記錄N條日誌，日誌中會記錄待刪除記錄的「_id」字段，與用戶的刪除請求的參數無關。

update操做

下面再看下更新操做對應的oplog的日誌數量和格式。

首先插入三條記錄：

MongoDB Enterprise repa:PRIMARY> use test
switched to db test
MongoDB Enterprise repa:PRIMARY>
MongoDB Enterprise repa:PRIMARY> db.users.insert({"name":"張三","age":NumberInt(10),"sex":"男"})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise repa:PRIMARY> db.users.insert({"name":"李四","age":NumberInt(11),"sex":"男"})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise repa:PRIMARY> db.users.insert({"name":"王五","age":NumberInt(12),"sex":"男"})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise repa:PRIMARY> db.users.find()
{ "_id" : ObjectId("60f2e2db0d98dc3b374199e1"), "name" : "張三", "age" : 10, "sex" : "男" }
{ "_id" : ObjectId("60f2e2db0d98dc3b374199e2"), "name" : "李四", "age" : 11, "sex" : "男" }
{ "_id" : ObjectId("60f2e2dc0d98dc3b374199e3"), "name" : "王五", "age" : 12, "sex" : "男" }

再執行更新操做：

MongoDB Enterprise repa:PRIMARY> db.users.update({"sex":"男"},  {"$inc":{"age":NumberInt(1)}}, false, true)
WriteResult({ "nMatched" : 3, "nUpserted" : 0, "nModified" : 3 })
MongoDB Enterprise repa:PRIMARY> db.users.find()                                                          
{ "_id" : ObjectId("60f2e2db0d98dc3b374199e1"), "name" : "張三", "age" : 11, "sex" : "男" }
{ "_id" : ObjectId("60f2e2db0d98dc3b374199e2"), "name" : "李四", "age" : 12, "sex" : "男" }
{ "_id" : ObjectId("60f2e2dc0d98dc3b374199e3"), "name" : "王五", "age" : 13, "sex" : "男" }

從返回結果能夠看到，更新操做執行成功，並更新了三條記錄，下面看下oplog的日誌：

MongoDB Enterprise repa:PRIMARY> use local
switched to db local
MongoDB Enterprise repa:PRIMARY> db.oplog.rs.find({"ns":"test.users","op":"u","wall":{"$gt":ISODate("2021-07-17T13:50:57.689Z")}})
{ "ts" : Timestamp(1626530575, 1), "t" : NumberLong(2), "h" : NumberLong("-6359278368726841648"), "v" : 2, "op" : "u", "ns" : "test.users", "ui" : UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"), "o2" : { "_id" : ObjectId("60f2e2db0d98dc3b374199e1") }, "wall" : ISODate("2021-07-17T14:02:55.319Z"), "o" : { "$v" : 1, "$set" : { "age" : 11 } } }
{ "ts" : Timestamp(1626530575, 2), "t" : NumberLong(2), "h" : NumberLong("-4351658862590633053"), "v" : 2, "op" : "u", "ns" : "test.users", "ui" : UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"), "o2" : { "_id" : ObjectId("60f2e2db0d98dc3b374199e2") }, "wall" : ISODate("2021-07-17T14:02:55.319Z"), "o" : { "$v" : 1, "$set" : { "age" : 12 } } }
{ "ts" : Timestamp(1626530575, 3), "t" : NumberLong(2), "h" : NumberLong("5911110003695351597"), "v" : 2, "op" : "u", "ns" : "test.users", "ui" : UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"), "o2" : { "_id" : ObjectId("60f2e2dc0d98dc3b374199e3") }, "wall" : ISODate("2021-07-17T14:02:55.319Z"), "o" : { "$v" : 1, "$set" : { "age" : 13 } } }

和delete相似，update操做也是產生了三條日誌，選第一條分析：

{
    "ts": Timestamp(1626530575, 1),
    "t": NumberLong(2),
    "h": NumberLong("-6359278368726841648"),
    "v": 2,
    "op": "u",   // 更新操做
    "ns": "test.users",  // 數據庫test，集合是users
    "ui": UUID("edabbd93-76eb-42be-b54a-cdc29eb1f267"),
    "o2": {  // 更新操做的查詢條件，使用的記錄的_id
        "_id": ObjectId("60f2e2db0d98dc3b374199e1")
    },
    "wall": ISODate("2021-07-17T14:02:55.319Z"),
    "o": {  // 更新操做的更新內容，原始的inc操做符轉變爲set操做符，能夠知足冪等性
        "$v": 1,
        "$set": {
            "age": 11
        }
    }
}

從上面日誌分析能夠獲得結論：

用戶的一次更新請求，若是更新了N條記錄，那麼oplog中將記錄N條日誌，日誌中記錄待更新記錄的「_id」字段爲查詢條件，更新操做使用的是set操做符，並非用戶的更新操做符。

小結

從上面的delete和update操做對應的oplog日誌分析能夠看出，oplog記錄的不是用戶的原始命令，而是對應的邏輯命令，經過這種方式能夠知足oplog的冪等性，可是也會衍生出可能產生大量oplog記錄的問題，須要用戶根據業務模型的須要，來選擇合適的oplog大小。