Mongodb oplog

在MongoDB复制集中,oplog信息存储在oplog.rs集合中。

oplog.rs集合是一个固定大小的集合(capped collection),它位于local数据库中。

当我们在源MongoDB实例上启用了复制(replication)功能,MongoDB会自动在local数据库中创建oplog.rs集合。此后,所有在该实例上的写操作都会生成对应的oplog记录,并插入到oplog.rs集合中。

从节点就可以通过tailing(尾随)这个oplog.rs集合来获得主节点的写操作记录,并在自己节点上重放这些操作,实现主从的数据同步。

oplog提供了数据库中的所有历史写操作的记录,这使得从节点可以随时通过读取oplog来与主节点的数据状态达到一致,无论从节点何时加入复制集。这使得MongoDB复制具有很强的容错能力。

oplog中的oplog记录按时间戳(ts)进行排序,从而保留了所有历史更新操作的完整顺序。

对于开启journaling的MongoDB,oplog与journal文件一起,可以用于进行点时间恢复(point in time recovery),将实例恢复到任意时间点的状态。
所以,oplog是MongoDB复制集工作的核心机制。它存储在local数据库的oplog.rs集合中,包含了数据库中全部历史写操作,是支持从节点与主节点数据同步的基础。

oplog是MongoDB复制集中的一个特殊的资源集合(capped collection),它存储了对数据库执行的所有更新操作的记录。oplog用来支持复制集中的数据同步。

oplog中的每个文档都代表数据库中的一个更新操作,并且包含以下字段:

• ts: 时间戳,记录操作的执行时间。
• h: 操作的散列值,用于确认操作的目标和值。
• v: 版本,格式是{主节点ID}{值递增},用于确认操作的顺序。
• op: 操作类型,可以是i(insert)、u(update)、d(delete)、c(db cmd)、n(no op)。
  • i : 插入操作
  • u : 更新操作
  • d : 删除操作
  • c : 命令操作(db cmd)
  • n : 空操作 (当重复执行幂等操作时)
  • o: 操作对象,对于更新和删除操作来说,这是被更新或删除的记录。对于指令操作,这是执行的命令对象。
• o2: 操作对象的新版本(如果有)。只有在更新操作中才包含此字段。
• ns: 被操作的命名空间,格式是db.collection。
• ui: 当op=i(insert)时,这个是_id的值。对其他操作来说,这个字段不存在。

例如,一个oplog文档可能如下:

{
   "ts" : Timestamp(1598584894, 1), 
   "h" : NumberLong("6305925108597842513"),
   "v" : 2,
   "op" : "i", 
   "ns" : "test.users",
   "ui" : UUID("b3fe353c-97cb-40d8-a7f4-61324299246e"),
   "o" : { 
      "_id" : UUID("b3fe353c-97cb-40d8-a7f4-61324299246e"),
      "name" : "John"
   }
}

这代表在test.users集合中插入了一条_id为b3fe353c-97cb-40d8-a7f4-61324299246e,name为John的记录。
oplog通过这种方式记录数据库的所有更新操作,复制集中的从节点可以通过读取oplog中的操作来与主节点同步数据,实现数据库的异步复制。
所以,oplog是MongoDB复制集工作的核心,它保存了全部历史更新操作,支持从节点与主节点的数据同步。我们在使用MongoDB时,也会经常手动读取oplog来做各种定制化的数据同步或消息订阅等工作。