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

Question

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

如果我有一个写入密集型集合，大约每 30 秒插入一批约 20K 文档，我是否/应该考虑将 oplog 大小增加到默认值之外？我有一个 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
}

Answer 1

当前主节点的 oplog 大小越大，副本集成员能够保持离线状态而不会落后于主节点太远的时间窗口就越长。如果它确实落后太多，则需要完全重新同步。

db.getReplicationInfo() 返回的字段 timeDiffHours 报告 oplog 当前已记录了多少小时的数据。当 oplog 填满并开始覆盖旧条目后，然后开始监视该值。尤其是在写入负载较重的情况下(此时该值会减小)，请执行此操作。如果您假设它永远不会低于 N 小时，那么 N 是您可以容忍副本集成员暂时离线的最大小时数(例如，为了定期维护，或者进行离线备份，或者在硬件发生故障的情况下)失败)而不执行完全重新同步。然后，该成员在重新上线后将能够自动 catch 主要成员。

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

我在这里假设您在所有副本集成员上保持 oplog 的大小恒定，这是一个合理的做法。如果没有，则规划具有最小 oplog 的副本集成员当选为主成员的场景。

(回答您的另一个问题:与多次更新类似，批量插入也会分散到oplog中的多个操作中)

编辑:请注意，数据导入和批量插入/更新将数据写入 oplog 的速度比应用程序在典型重负载时的速度要快得多。重申一下:对于 oplog 填满需要多长时间，请保守估计。