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