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数据结构# 获取一条oplogdb.oplog.rs.find().skip(1).limit(1).toArray()ts: 8字节的时间戳，由4字节unix timestamp + 4字节自增计数表示。这个值很重要，在选举(如master宕机时)新primary时，会选择ts最大的那个secondary作为新primaryh: 此操作的独一无二的IDop: 1字节的操作类型	"i": insert	"u": update	"d": delete	"c": db cmd	"db": 声明当前数据库 (其中ns 被设置成为=>数据库名称+ '.')	"n": no op,即空操作，其会定期执行以确保时效性ns: 操作所在的namespaceo: 操作所对应的document，即当前操作的内容（比如更新操作时要更新的的字段和值）o2: 在执行更新操作时的where条件，仅限于update时才有该属性b: bool,删除时候出现v: oplog 的版本