关于Oplog的官网说明 ： https://docs.mongodb.com/manual/core/replica-set-oplog/

1、Oplog简介。Oplog即操作日志(operation log)是用于保存Mongodb数据库所有数据操作记录(实际上只记录改动数据库数据的操作记录，即增/删/改)的固定大小集合(Capped Collections)。类比过来的话就相当于是mysql的binlog日志。

Oplog的存在及大地方便了MongoDB副本集的各节点的数据同步。

2、副本集数据同步的过程。

其流程大概如下：Primary节点写入数据，Secondary节点读取Pirmary的oplog然后再通过异步进程复制数据，之后再将操作记录写到自己的oplog。①如果某个备份点由于某些原因挂掉了，重新启动后就会自动从oplog的最后一个操作开始同步；同步完成后，将操作写入自己的oplog。②所有的副本集成员都会有一个oplog的副本 ③oplog中的每次操作都是幂等的，即即便有操作被同步了两次或多次也不会有什么负面影响。④为了提高复制效率，副本集中的所有节点之间会相互的进行心跳检测(ping),每个节点都可以从其他节点获取oplog。

注：对于固定集合(Capped Collections)就把他想成一个环形队列，当集合空间用完后，再插入元素就会覆盖最初始的头部元素。

3、Oplog的默认大小

当你首次启动副本集成员的时候，如果你没有指定oplog的打下，mongodb会自动创建一个默认大小的oplog。对于Unix 和Windows系统，默认oplog的大小取决于引擎，如下：

在大多数情况下，默认的oplog大小是足够用的。例如，如果oplog占可用磁盘空间的5%，并在24小时的操作中填满，则副本节点可以实现24小时不从oplog复制数据也不会影响最终同步(例如副本节点宕机)。大多数副本集的操作量要小得多，它们的oplog可以容纳更多的操作。

通常系统中存在以下操作的话，可能就需要设置更大的Oplog值来避免数据的丢失。

①一次性更新大量数据 ②删除域插入大致同样数量的数据 ③大量的更新现有数据

4、oplog常用命令

（1）查看oplog的状态：

rs.printReplicationInfo()

（2）查看oplog存储设置的大小

use local

db.oplog.rs.stats().maxSize

（3）查看oplog最大大小和现在占用大小以及记录时长

db.getReplicationInfo()

（4）更改副本集成员的Oplog大小  

db.adminCommand({replSetResizeOplog: 1, size: 15000})

注意点：

（1）sharding架构下，mongos不能查看oplog，但是我们可以到每个mongod实例去看。

另外，上面诸多命令在单mongo实例下也是不能用的(提示没有探测到副本集)。

与之类似的玩法：

redis中的玩法：

其实这个玩法和redis的AOF持久化完全就是一个思想，AOF持久化就是以日志的形式记录服务器所处理的数据改动操作，记录下来；万一redis挂了进行数据恢复的时候就先恢复RDB持久化下来的二进制压缩存储，然后以之为契机重现一遍写 增、删、改操作即可。

mysql中的玩法：

MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复。Binlog日志的两个最重要的使用场景
①MySQL主从复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves来达到master-slave数据一致的目的
②数据恢复：通过使用 mysqlbinlog工具来使恢复数据