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 的版本