在Mongodb3.6版本開始，可以使用命令[`replSetResizeOplog`]來修改副本集成員的oplog大小， **從secondry節點開始修改，然后依次到主節點（只能在運行了WiredTiger存儲引擎的副本集成員上執行）。** 如果副本集強制執行身份驗證，則必須以具有修改本地數據庫權限的用戶身份進行身份驗證，例如clusterManager或clusterAdmin角色。 我們可以通過命令查看oplog的大小 ``` rs1:PRIMARY> use local switched to db local rs1:PRIMARY> db.oplog.rs.stats().maxSize NumberLong("16777216000") rs1:PRIMARY> ``` maxSize字段以字節為單位顯示集合大小（上邊顯示大概16GB） 需要注意的是我們更改oplog大小，運行replSetResizeOplog將所需的大小(以兆字節為單位)作為大小參數傳遞。指定的大小必須大于990，即990兆字節，也就是修改時單位是MB。 我們將secondry節點的oplog 20G修改為50G； ``` rs1:SECONDARY> rs.slaveOk() rs1:SECONDARY> use local switched to db local rs1:SECONDARY> db.oplog.rs.stats().maxSize NumberLong("21474836480") rs1:SECONDARY> db.adminCommand({replSetResizeOplog: 1, size: 51200}) { "ok" : 1, "operationTime" : Timestamp(1593672183, 2), "$clusterTime" : { "clusterTime" : Timestamp(1593672183, 2), "signature" : { "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId" : NumberLong(0) } } } rs1:SECONDARY> db.oplog.rs.stats().maxSize NumberLong("53687091200") s1:SECONDARY> ``` 為什么需要修改oplog大小呢，mongodb副本集插入、更新、刪除操作保存在oplog中（類似mysql中的binlog），如果數據庫寫入量大oplog設置太小，新的日志會把老的覆蓋掉，復制集節點同步出現異常。 如下列錯誤： ``` 2019-05-22T17:36:38.676+0800 I REPL [replication-0] We are too stale to use 192.168.6.34:27012 as a sync source. Blacklisting this sync source because our last fetched timestamp: Timestamp(1556640001, 2) is before their earliest timestamp: Timestamp(1557506621, 2) for 1min until: 2019-05-22T17:37:38.676+0800 2019-05-22T17:36:38.676+0800 I REPL [replication-0] could not find member to sync from ``` 出現這樣情況就需要重新初始化secondry節點，從新同步數據了。下一篇我們來聊聊oplog。