我应该增加MongoDB oplog文件的大小吗？

我知道oplog文件会将多个更新拆分为单独的更新，但是批插入呢？这些也被分割成单独的插入物吗

<如果我有一个写密集型的集合，大约每30秒插入一批20K文档，我是否应该考虑增加我的OPLG大小超过默认值？我有一个3人副本集，mongod运行在64位Ubuntu服务器上，Mongodb数据位于100GB卷上

以下是一些可能有用也可能无用的数据：

    gs_rset:PRIMARY> db.getReplicationInfo()
    {
        "logSizeMB" : 4591.3134765625,
        "usedMB" : 3434.63,
        "timeDiff" : 68064,
        "timeDiffHours" : 18.91,
        "tFirst" : "Wed Oct 24 2012 22:35:10 GMT+0000 (UTC)",
        "tLast" : "Thu Oct 25 2012 17:29:34 GMT+0000 (UTC)",
        "now" : "Fri Oct 26 2012 19:42:19 GMT+0000 (UTC)"
    }
    gs_rset:PRIMARY> rs.status()
    {
        "set" : "gs_rset",
        "date" : ISODate("2012-10-26T19:44:00Z"),
        "myState" : 1,
        "members" : [
            {
                "_id" : 0,
                "name" : "xxxx:27017",
                "health" : 1,
                "state" : 1,
                "stateStr" : "PRIMARY",
                "uptime" : 77531,
                "optime" : Timestamp(1351186174000, 1470),
                "optimeDate" : ISODate("2012-10-25T17:29:34Z"),
                "self" : true
            },
            {
                "_id" : 1,
                "name" : "xxxx:27017",
                "health" : 1,
                "state" : 2,
                "stateStr" : "SECONDARY",
                "uptime" : 76112,
                "optime" : Timestamp(1351186174000, 1470),
                "optimeDate" : ISODate("2012-10-25T17:29:34Z"),
                "lastHeartbeat" : ISODate("2012-10-26T19:44:00Z"),
                "pingMs" : 1
            },
            {
                "_id" : 2,
                "name" : "xxxx:27017",
                "health" : 1,
                "state" : 2,
                "stateStr" : "SECONDARY",
                "uptime" : 61301,
                "optime" : Timestamp(1351186174000, 1470),
                "optimeDate" : ISODate("2012-10-25T17:29:34Z"),
                "lastHeartbeat" : ISODate("2012-10-26T19:43:59Z"),
                "pingMs" : 1
            }
        ],
        "ok" : 1
    }

gs_rset:PRIMARY> db.printCollectionStats()
dev_fbinsights
{
    "ns" : "dev_stats.dev_fbinsights",
    "count" : 6556181,
    "size" : 3117699832,
    "avgObjSize" : 475.53596095043747,
    "storageSize" : 3918532608,
    "numExtents" : 22,
    "nindexes" : 2,
    "lastExtentSize" : 1021419520,
    "paddingFactor" : 1,
    "systemFlags" : 0,
    "userFlags" : 0,
    "totalIndexSize" : 1150346848,
    "indexSizes" : {
        "_id_" : 212723168,
        "fbfanpage_id_1_date_1_data.id_1" : 937623680
    },
    "ok" : 1
}

---

当前主操作日志的大小越大，副本集成员保持脱机状态的时间窗口就越长，而不会落后于主操作日志太远。如果它确实落后太多，它将需要一次完全的重新同步

db.getReplicationInfo（）返回的字段

timeDiffHours

报告oplog当前记录的数据小时数。oplog填满并开始覆盖旧条目后，开始监视此值。尤其是在写负载较重的情况下（该值将降低）。如果您随后假设它永远不会降到N小时以下，则N是允许副本集成员在不执行完全重新同步的情况下暂时脱机（例如，进行定期维护、进行脱机备份或发生硬件故障）的最大小时数。然后，该成员将能够在重新联机后自动赶上初级用户

如果您对N的低值不满意，那么应该增加oplog的大小。这完全取决于您的维护窗口的长度，或者您或您的ops团队对灾难场景的响应速度。在分配多少磁盘空间方面要自由，除非您迫切需要该空间

我在这里假设在所有副本集成员上保持oplog的大小不变，这是一件合理的事情。如果不是，则计划这样一个场景，其中oplog最小的副本集成员被选为主副本

（回答您的另一个问题：与多个更新类似，批插入也被分散到oplog中的多个操作中）

---

编辑：请注意，数据导入和大容量插入/更新将比应用程序在典型重载情况下将数据写入oplog的速度快得多。重申：对于oplog需要多长时间才能填充，请保守估计。

谢谢您的回复。此外，我实际上保持所有oplog的大小相同。仅供参考：要查看oplog的最大大小，请在mongo js shell中使用local然后

db.oplog.rs.stats（）

并查找

max

。上面的

logSizeMB

字段是实际分配的存储大小，而不是最大值。请注意

max

不符合“”（例如：

db.oplog.rs.stats（1024）

）。这适用于mongod版本2.0.4更改oplog大小是件麻烦事，因此创建足够大的oplog大小，以使用守护进程标志“-oplogSize 4096”或类似数字开始。请注意，如果一个盒子上有多个碎片（就像我一样），oplogsize的默认值为磁盘大小的5%（不可用空间，总大小），这意味着在添加任何数据之前，一个盒子上的20个碎片会填满100%的空间。