1：oplog简介
oplog是local库下的一个固定集合，Secondary就是通过查看Primary 的oplog这个集合来进行复制的。每个节点都有oplog，记录这从主节点复制过来的信息，这样每个成员都可以作为同步源给其他节点。
2：副本集数据同步的过程
副本集中数据同步的详细过程：Primary节点写入数据，Secondary通过读取Primary的oplog得到复制信息，开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败（只有当同步源的数据损坏或者数据与主节点不一致时才可能发生），则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，将信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑到这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。可以简单的将其视作Mysql中的binlog。
3：同步类型
initial sync（初始化）：这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复，或者向副本集中添加新的成员的时候，默认的，副本集中的节点会从离它最近的节点复制oplog来同步数据，这个最近的节点可以是primary也可以是拥有最新oplog副本的secondary节点。
replication（复制）：在初始化后这个操作会一直持续的进行着,以保持各个secondary节点之间的数据同步。
4：Oplog大小：
capped collection是MongoDB中一种提供高性能插入、读取和删除操作的固定大小集合，当集合被填满的时候，新的插入的文档会覆盖老的文档。
在64位的Linux,Solaris,FreeBSD以及Windows系统上，MongoDB会分配磁盘剩余空间的5%作为oplog的大小，如果这部分小于1GB则分配1GB的空间
在64的OS X系统上会分配183MB
在32位的系统上则只分配48MB
5：oplog的增长速度
oplog是固定大小，他只能保存特定数量的操作日志，通常oplog使用空间的增长速度跟系统处理写请求的速度相当，如果主节点上每分钟处理1KB的写入数据，那么oplog每分钟大约也写入1KB数据。如果单次操作影响到了多个文档（比如删除了多个文档或者更新了多个文档）则oplog可能就会有多条操作日志。db.testcoll.remove() 删除了1000000个文档，那么oplog中就会有1000000条操作日志。如果存在大批量的操作，oplog有可能很快就会被写满了。
6：oplog的监控
## 查看 oplog 的状态
shard1:PRIMARY> rs.printReplicationInfo()
configured oplog size: 1674.7353515625MB
log length start to end: 102397secs (28.44hrs)
oplog first event time: Tue Oct 09 2018 18:17:42 GMT+0800 (CST)
oplog last event time: Wed Oct 10 2018 22:44:19 GMT+0800 (CST)
now: Wed Oct 10 2018 22:44:23 GMT+0800 (CST
## 查看集群 Oplog 使用情况
shard1:PRIMARY> db.getReplicationInfo()
{
"logSizeMB" : 1674.7353515625,
"usedMB" : 0.33,
"timeDiff" : 102307,
"timeDiffHours" : 28.42,
"tFirst" : "Tue Oct 09 2018 18:17:42 GMT+0800 (CST)",
"tLast" : "Wed Oct 10 2018 22:42:49 GMT+0800 (CST)",
"now" : "Wed Oct 10 2018 22:42:52 GMT+0800 (CST)"
}
## 查看集群延迟情况
shard1:PRIMARY> db.printSlaveReplicationInfo()
source: 10.100.25.42:27001
syncedTo: Wed Oct 10 2018 22:40:39 GMT+0800 (CST)
0 secs (0 hrs) behind the primary