我是否应该增加MongoDB Oplog文件的大小

Question

我知道，oplog文件会将多个更新分为单个更新，但是批处理插入又如何？这些也分为单个插入物吗？

如果我有一个大约每30秒插入〜20k文档的批次批量的集合，我/是否应该考虑将我的oplog大小增加到默认值之外？我有一个3个成员副本集，而蒙古德（Mongod）正在安装64位Ubuntu Server上，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
}

Answer 1

越大的当前主oplog的大小越大，复制品集成员将能够离线的时间窗口越长，而不会落后于主的时间窗口。如果它确实落后了，它将需要一个完整的Resync。

db.getReplicationInfo()返回的字段timeDiffHours报告了OPLOG当前已记录了多少小时的数据。OPLOG填充并开始覆盖旧条目后，然后开始监视此值。尤其是在沉重的写入负载下（其中值降低）。如果您认为它永远不会降至n小时以下，那么n是您可以忍受临时脱机的最大小时数（例如，定期维护或进行离线备份，或者在硬件发生硬件时失败）不执行完整的Resync。然后，该成员可以在返回在线后自动赶上初选。

如果您对N的低点不满意，则应增加OPLOG的大小。这完全取决于您的维护窗口的长时间，或者您或您的OPS团队可以对灾难方案做出响应的速度。除非您对该空间有迫切的需求，否则要自由地为其分配的磁盘空间

我在这里假设您在所有复制设置成员上保持oplog恒定的大小，这是一件合理的事情。如果没有，请计划以最小OPLOG的复制构件将选举产生的场景。

（要回答您的其他问题：与多重日期类似，批处理插入物也被散布到OPLOG中的多个操作中）

编辑：请注意，数据导入和批量插入/更新将比您的应用程序在典型的重负载下更快地编写数据。重申：在您的估计中要保守，填充OPLOG需要花费多少时间。