在默认情况下,oplog分配的是5%的空闲磁盘空间。通常而言,这是一种合理的设置。可以通过mongod —oplogSize来改变oplog的日志大小。
oplog是capped collection,因为oplog的特点(不能太多把磁盘填满了,固定大小)需要,MongoDB才发明了capped collection(the oplog is actually the reason capped collections were invented).
oplog的位置
replica sets 架构下:
local.oplog.rs
sharding 架构下,mongos下不能查看oplog,可到每一片去看。
oplog的格式
MongoDB 2.0版本
{
"ts" : {
"t" : 1354919611000,
"i" : 196
},
"h" : NumberLong("-8946637877024029255"),
"op" : "i",
"ns" : "msg.msgToSend",
"o" : {
"_id" : ObjectId("50c26ecae7d64ae0b5f36cfe"),
...
MongoDB 2.2版本
可以看到有个字段"fromMigrate" : true,之前以为是从2.0升级过来的,后查看源码发现并发如此,fromMigrate指的是chunk是迁移过来的,分片里的块移动,详见src/mongo/s/d_migrate.cpp,
新搭建的结构形如:
PRIMARY> db.version()
2.2.2
PRIMARY> db.oplog.rs.findOne()
{
"ts" : Timestamp(1364186197000, 58),
"h" : NumberLong("-7878220425718087654"),
"v" : 2,
"op" : "u",
"ns" : "exaitem_gmsbatchtask.jdgmsbatchtask",
"o2" : {
"_id" : "83f09a98-6a41-497b-a988-99ba5399d296"
},
"status" : 2,
"content" : "",
"type" : 17,
"business" : "832722",
"optype" : 2,
"addDate" : ISODate("2013-03-25T04:36:38.511Z"),
"modifyDate" : ISODate("2013-03-25T04:36:39.131Z"),
"source" : 5
}
}
MongoDB 2.4版本
格式大同小异,2.4版本又改回去了。
ts格式2.2版本中是Timestamp(1364186197000, 58)形式,
MongoDB 2.0版本及MongoDB2.4版本是{ "t" : 1361948104000, "i" : 325 }形式,
另外若用MongoDB2.4版本的客户端(mongo)查看2.2版本的,看到的是MongoDB2.4版本的格式,这个只与mongo版本有关。
oplog相关字段含义
其中op,可以是如下几种情形之一:
"i": insert
"u": update
"d": delete
"c": db cmd
"db":声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')
"n": no op, 即空操作,其会定期执行以确保时效性 。
20130719更新:今天发现修改配置,会产生 "n" 操作
{ "ts" : Timestamp(1372320938000, 1), "h" : NumberLong("2050563086860406946"), "v" : 2, "op" : "n", "ns" : "", "o" : { "msg" : "Reconfig set", "version" : 6 } }
{ "ts" : Timestamp(1372318223000, 1), "h" : NumberLong("512600544405470974"), "v" : 2, "op" : "n", "ns" : "", "o" : { "msg" : "Reconfig set", "version" : 4 } }
除了以上这些,还有两个bool型的字段,一个是上面提到的fromMigrate,另一是字段b,仔细看oplog我们发现有"b":true的文档,是在delete和update操作时的bool值(update一个或多个)。