本篇文章为大家展示了MongoDB中 oplog的作用是什么，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。
1：oplog简介
oplog是local库下的一个固定集合，Secondary就是通过查看Primary 的oplog这个集合来进行复制的。每个节点都有oplog，记录这从主节点复制过来的信息，这样每个成员都可以作为同步源给其他节点。
Oplog 可以说是Mongodb Replication的纽带了。
2：副本集数据同步的过程
副本集中数据同步的详细过程：Primary节点写入数据，Secondary通过读取Primary的oplog得到复制信息，开始复制数据并且将复制信息写入到自己的oplog。如果某个操作失败（只有当同步源的数据损坏或者数据与主节点不一致时才可能发生），则备份节点停止从当前数据源复制数据。如果某个备份节点由于某些原因挂掉了，当重新启动后，就会自动从oplog的最后一个操作开始同步，同步完成后，将信息写入自己的oplog，由于复制操作是先复制数据，复制完成后再写入oplog，有可能相同的操作会同步两份，不过MongoDB在设计之初就考虑到这个问题，将oplog的同一个操作执行多次，与执行一次的效果是一样的。
当Primary进行写操作的时候，会将这些写操作记录写入Primary的Oplog 中，而后Secondary会将Oplog 复制到本机并应用这些操作，从而实现Replication的功能。
同时由于其记录了Primary上的写操作，故还能将其用作数据恢复。
可以简单的将其视作Mysql中的binlog。
3：oplog的增长速度
oplog是固定大小，他只能保存特定数量的操作日志，通常oplog使用空间的增长速度跟系统处理写请求的速度相当，如果主节点上每分钟处理1KB的写入数据，那么oplog每分钟大约也写入1KB数据。如果单次操作影响到了多个文档（比如删除了多个文档或者更新了多个文档）则oplog可能就会有多条操作日志。db.testcoll.remove() 删除了1000000个文档，那么oplog中就会有1000000条操作日志。如果存在大批量的操作，oplog有可能很快就会被写满了。
Oplog 是一个capped collection。
在64位的Linux, Solaris, FreeBSD, and Windows 系统中，Mongodb默认将其大小设置为可用disk空间的5%（默认最小为1G，大为50G），或也可以在mongodb复制集实例初始化之前将mongo.conf中oplogSize设置为我们需要的值。
local.oplog.rs 一个capped collection集合.可在命令行下使用--oplogSize 选项设置该集合大小尺寸.
但是由于Oplog 其保证了复制的正常进行，以及数据的安全性和容灾能力。
4：oplog注意事项：
local.oplog.rs特殊的集合。用来记录Primary节点的操作。
oplog的大小
capped collection是MongoDB中一种提供高性能插入、读取和删除操作的固定大小集合，当集合被填满的时候，新的插入的文档会覆盖老的文档。
所以，oplog表使用capped collection是合理的，因为不可能无限制的增长oplog。MongoDB在初始化副本集的时候都会有一个默认的oplog大小：
在64位的Linux,Solaris,FreeBSD以及Windows系统上，MongoDB会分配磁盘剩余空间的5%作为oplog的大小，如果这部分小于1GB则分配1GB的空间
在64的OS X系统上会分配183MB
在32位的系统上则只分配48MB
oplog的大小设置是值得考虑的一个问题，如果oplog size过大，会浪费存储空间；如果oplog size过小，老的oplog记录很快就会被覆盖，那么宕机的节点就很容易出现无法同步数据的现象。
比如，基于上面的例子，我们停掉一个备份节点（port=33333），然后通过主节点插入以下记录，然后查看oplog，发现以前的oplog已经被覆盖了。
通过MongoDB shell连接上这个节点，会发现这个节点一直处于RECOVERING状态。
解决方法：
在副本集中，有两种数据同步方式：
initial sync（初始化）：这个过程发生在当副本集中创建一个新的数据库或其中某个节点刚从宕机中恢复，或者向副本集中添加新的成员的时候，默认的，副本集中的节点会从离它最近的节点复制oplog来同步数据，这个最近的节点可以是primary也可以是拥有最新oplog副本的secondary节点。
该操作一般会重新初始化备份节点，开销较大
replication（复制）：在初始化后这个操作会一直持续的进行着,以保持各个secondary节点之间的数据同步。
当遇到上面例子中无法同步的问题时，只能使用以下两种方式进行initial sync了
第一种方式就是停止该节点，然后删除目录中的文件，重新启动该节点。这样，这个节点就会执行initial sync
注意：通过这种方式，sync的时间是根据数据量大小的，如果数据量过大，sync时间就会很长
同时会有很多网络传输，可能会影响其他节点的工作
第二种方式，停止该节点，然后删除目录中的文件，找一个比较新的节点，然后把该节点目录中的文件拷贝到要sync的节点目录中
通过上面两种方式中的一种，都可以重新恢复"port=33333"的节点。改变一直处于RECOVERING状态的错误。
查看oplog的信息
通过"db.printReplicationInfo()"命令可以查看oplog的信息
字段说明：
configured oplog size： oplog文件大小
log length start to end: oplog日志的启用时间段
oplog first event time: 第一个事务日志的产生时间
oplog last event time: 最后一个事务日志的产生时间
now: 现在的时间
通过"db.printSlaveReplicationInfo()"可以查看slave的同步状态
副本节点中执行db.printSlaveReplicationInfo()命令可以查看同步状态信息
source——从库的IP及端口
syncedTo——当前的同步情况，延迟了多久等信息
上述内容就是MongoDB中 oplog的作用是什么，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注创新互联-成都网站建设公司行业资讯频道。