在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。