mysql binlog oplog_MongoDB oplog 详解

oplog 简介

oplog 是local库下的一个固定集合，Secondary就是通过查看Primary的oplog这个集合来进行复制的。每个节点都有oplog，记录从主节点复制过来的信息，这样每个成员都可以作为同步源给其它节点。

oplog 可以说是MongoDB Replication的纽带。

复本集数据同步的过程

Primary节点写入数据，Secondary 通过读取primary的oplog得到复制信息，开始复制数据并且将复制的信息写入到自己的oplog。如果某个操作失败(只有当同步源损坏或者数据与主节点不一致才可能发生)，则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，就信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑了这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。

作用： 当Primary进行写操作的时候，会将这些操作记录写入Primary的Oplog中，而后Secondary会将Oplog复制到本机并应用这些操作，从而实现Replication的功能。

可以用作数据恢复，类似于MySQL的binlog

特性： 封顶表 Capped collection ，滚动覆盖写入，固定大小，不能删除数据

默认大小： 64 位 linux，windows操作系统下位当前分区可用空间5%，体积不会超过50G，通过--oplogSize=4096(mb)，最小4k

在第一个启动复制集中的节点是，MongoDB会建立Oplog，会有一个默认的大小，这个取决于机器的操作系统

# 查看oplog的状态，输出的信息包括oplog日志大小，操作日志记录的起始时间

rs.printReplicationInfo()

# 查看oplog的状态、大小、存储的时间范围

db.getReplicationInfo()

# oplog数据结构

# 获取一条oplog

db.oplog.rs.find().skip(1).limit(1).toArray()

ts: 8字节的时间戳，由4字节unix timestamp + 4字节自增计数表示。这个值很重要，

在选举(如master宕机时)新primary时，会选择ts最大的那个secondary作为新primary

h: 此操作的独一无二的ID

op: 1字节的操作类型

"i": insert

"u": update

"d": delete

"c": db cmd

"db": 声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')

"n": no op,即空操作，其会定期执行以确保时效性

ns: 操作所在的namespace

o: 操作所对应的document，即当前操作的内容(比如更新操作时要更新的的字段和值)

o2: 在执行更新操作时的where条件，仅限于update时才有该属性

b: bool,删除时候出现

v: oplog 的版本