浅谈 Mongo DB 的 oplog

当我们使用 Mysql 数据库的时候,可以开启 binlog,除了做主从同步以外,我们还可以通过观察检索binlog日志知道某个表在指定时间内的操作历史。

那么在 Mongo DB 中是否也存在这样的东东呢?答案是肯定的,这个东西就是 oplog。

当Mongo DB 被设置成主库时(这一点很重要),在 local db 下有个 collection 叫oplog.$main ,这个就是Mongo 的 oplog。

例如,我们在 test 库上创建一个 collection 叫 employee,插入一个叫“小王”的员工,然后将这个小王变性为“女”,删除掉这个叫小王的员工。这就是一个典型的CRUD操作了。

> use test
switched to db test
> db.employee.insert({name:"小王", sex:"男"})
> db.employee.update({name:"小王"}, {$set : {sex:"女"}})
> db.employee.find();
{ "_id" : ObjectId("521272c7dd01ef8a1598a522"), "name" : "小王", "sex" : "女" }
> db.employee.remove({name:"小王"})
> db.employee.find();
>

我们查查对 employee 进行操作的所有的 oplog 记录

> use local
switched to db local
> db.oplog.$main.find({ns : "test.employee"});
{ "ts" : { "t" : 1376940743000, "i" : 1 }, "op" : "i", "ns" : "test.employee", "o" : { "_id" : ObjectId("521272c7dd01ef8a1598a522"), "name" : "小王", "sex" : "男" } }
{ "ts" : { "t" : 1376940770000, "i" : 1 }, "op" : "u", "ns" : "test.employee", "o2" : { "_id" : ObjectId("521272c7dd01ef8a1598a522") }, "o" : { "$set" : { "sex" : "女" } } }
{ "ts" : { "t" : 1376940828000, "i" : 1 }, "op" : "d", "ns" : "test.employee", "b" : true, "o" : { "_id" : ObjectId("521272c7dd01ef8a1598a522") } }
>

可以看到一共有3条,对应了新增、修改、和删除操作,字段含义如下:

ts:操作发生时的时间戳,这个时间戳包含两部分内容t和i,t是标准的时间戳(自1970年1月1日 00:00:00 GMT 以来的毫秒数)而i是一个序号,目的是为了保证 t 与 i 组合出的 Mongo 时间戳 ts 可以唯一的确定一条操作记录
op:操作类型,插入对应i;更新对应u;删除对应d;但有一种情况是n,它表示无操作(no-op),紧紧代表一个消息信息。
ns:这个操作的库和collection的组合
o与o2:他们都是操作相关的数据内容

关于oplog的具体内容可以参考下面两个链接

http://stackoverflow.com/questions/11805057/reading-mongodb-binlogs

http://www.kchodorow.com/blog/2010/10/12/replication-internals/

MongoDB的oplog默认大小是空闲磁盘空间的5%。因为有理论认为如果你在单位时间(假设为x)内写了5% 的磁盘空间,那么你将在 19x 的时间内将磁盘耗尽。关于如何调整oplog的大小可以参考下面链接

http://www.kchodorow.com/blog/2011/02/22/resizing-your-oplog/

我之前做了一个对oplog进行查询的小工具。
使用时需要先配置要查询的条件(oplog.properties 文件),例如

# 欲查询的 Mongo DB 的主机、端口和库
mongo.host=172.0.0.1
mongo.port=40017
mongo.db=test

# 查询条件
#   query.collection - 要查询的 Mongo DB collection.
#   query.field       - 要查询的字段名称.
#   query.type        - 要查询的字段类型,支持内容为: "Integer", "String", "Boolean", "Long"
#   query.value       - 要查询的字段值.
#   query.if_value_null - 这个值如果为 "true" 表示要查询的字段值为null.
query.collection=employee
query.field=_id
query.type=String
query.value=521272c7dd01ef8a1598a522
query.if_value_null=false

# 输出相关参数
#  output.directory    - 希望输出文件的路径.
#  output.filename   - 希望输出的文件名,但事实上你得到两个文件:
#            filename.json (json format)
#            filename.html (html format)
output.directory=/tmp/
output.filename=output

在之前的例子中你已经发现了,更新时的查询条件是不会记录在oplog中的,但所有相关操作都会记录 _id 值。所以我这里直接查找_id值为521272c7dd01ef8a1598a522 的内容,那么假如记录被删除如何找到 _id 值呢?我想这就需要我们在设计业务逻辑时做一下妥协,如果要物理删除一条记录,最好在另一个库或日志文件中将这个记录原来的 _id 值记录一下。

执行后会生成两个文件,一个是json格式保存的oplog原始内容(方便二次处理),另一个是html格式方便阅读的内容,看起来如下图所示:

发表评论