mongodb复制集oplog mongodb数据复制

MongoDB副本集同步原理解析

在MongoDB的副本集中，节点之间是通过oplog来同步数据。Primary节点每执行一次数据写入，都会记录一条oplog，Secondary节点会持续不断的自Primary拉取oplog并在本地回放，从而确保各节点达到数据最终一致性。

Primary节点并发写入数据，时间点分别为t1、t2和t3，按时间先后排序为 t1 - t2 - t3；如果t1和t3先落库，t2后落库，那么在oplog集合中如何能保证有序呢？

MongoDB底层通用的存储引擎为WiredTiger、In-Memory，以WiredTiger为例，MongoDB管理层调用WiredTiger引擎接口向oplog集合中插入文档（即记录）；

WiredTiger会以 oplog 的 ts 字段作为 key、文档内容作为 value，写入一条 KV 记录，wiredtiger 会保证存储（btree 或 lsm 的方式都能保证）的文档按 key 来排序，这样就解决 “Primary节点oplog如何保证有序” 的问题；

并发写入多条oplog ts1、ts2、ts3和ts4，其中 ts1ts2ts3ts4，如果ts1、ts2和ts4先写入primary成功，ts3存在延迟，还未写入，此时secondary节点自pirmary拉取oplog在本地回放，如何保证有序呢？

MongoDB（wiredtiger 引擎）的解决方案是在读取oplog时进行限制，保证Secondary 节点看到一定是顺序的，具体实现机制如下：

如此既可以确保 “secondary节点在本地回放oplog时有序”

Secondary节点回放oplog在保证有序的前提下，如何保证高效呢？如下：

如果OpQueue队列中的oplog有对同一个collection的操作，后续并发进行数据回放时，如何保证同一个collections中两条oplog的执行顺序呢？

参考文档：

MongoDB 如何保证 oplog 顺序？

MongoDB复制集同步原理解析

相关问答

Q1: MongoDB主从

mongodb的集群搭建方式主要有三种，主从模式，Replica set模式，sharding模式, 三种模式各有优劣，适用于不同的场合，属Replica set应用最为广泛，主从模式现在用的较少，sharding模式最为完备，但配置维护较为复杂。本文为Replica Set模式。

在复制集中，主节点是唯一能够接收写请求的节点。MongoDB在主节点进行写操作，并将这些操作记录到主节点的oplog中。而从节点将会从oplog复制到其本机，并将这些操作应用到自己的数据集上。（复制集最多只能拥有一个主节点）

从节点通过应用主节点传来的数据变动操作来保持其数据集与主节点一致。从节点也可以通过增加额外参数配置来对应特殊需求。例如，从节点可以是non-voting或是priority 0.

仲裁节点即投票节点，其本身并不包含数据集，且也无法晋升为主节点。但是，旦当前的主节点不可用时，投票节点就会参与到新的主节点选举的投票中。仲裁节点使用最小的资源并且不要求硬件设备。投票节点的存在使得复制集可以以偶数个节点存在，而无需为复制集再新增节点 不要将投票节点运行在复制集的主节点或从节点机器上。 投票节点与其他 复制集节点的交流仅有：选举过程中的投票，心跳检测和配置数据。这些交互都是不加密的。

各节点使用不同角色节点配置

172.18.169.38:27017(primary)

172.18.169.39:27017(secondary)

172.18.169.39:27018(arbiter)

Q2: mongobd的复制集和mysql主从备份的区别

group_replication_member_expel_timeout 指定组复制组成员在产生怀疑之后，从组中排除怀疑失败的成员之前等待的时间（以秒为单位）。在产生怀疑之前的最初 5 秒检测时间不计入该时间。直到并包括 MySQL 8.0.20 在内，group_replication_member_expel_timeout 默认值均为 0，这意味着没有等待时间，并且在 5 秒钟的检测时间结束后，可疑成员应立即被驱逐。从 MySQL 8.0.21 开始，该值默认为 5，这意味着在 5 秒钟的检测时间后如果该节点还是不正常，那会在等 5 秒钟，如果可疑成员还是不正常，超过这个时间将被驱逐。

为验证该参数对集群影响，我们通过实验模拟不同时长的网络延迟，然后调整group_replication_member_expel_timeout 值观察该参数值对集群驱逐故障节点的影响。

Q3: MongoDB是什么，怎么用？看完你就知道了

MongoDB是一款为web应用程序和互联网基础设施设计的数据库管理系统。没错MongoDB就是数据库，是NoSQL类型的数据库。

（1）MongoDB提出的是文档、集合的概念，使用BSON（类JSON）作为其数据模型结构，其结构是面向对象的而不是二维表，存储一个用户在MongoDB中是这样子的。

使用这样的数据模型，使得MongoDB能在生产环境中提供高读写的能力，吞吐量较于mysql等SQL数据库大大增强。

（2）易伸缩，自动故障转移。易伸缩指的是提供了分片能力，能对数据集进行分片，数据的存储压力分摊给多台服务器。自动故障转移是副本集的概念，MongoDB能检测主节点是否存活，当失活时能自动提升从节点为主节点，达到故障转移。

（3）数据模型因为是面向对象的，所以可以表示丰富的、有层级的数据结构，比如博客系统中能把“评论”直接怼到“文章“的文档中，而不必像myqsl一样创建三张表来描述这样的关系。

（1）文档数据类型

SQL类型的数据库是正规化的，可以通过主键或者外键的约束保证数据的完整性与唯一性，所以SQL类型的数据库常用于对数据完整性较高的系统。MongoDB在这一方面是不如SQL类型的数据库，且MongoDB没有固定的Schema，正因为MongoDB少了一些这样的约束条件，可以让数据的存储数据结构更灵活，存储速度更加快。

（2）即时查询能力

MongoDB保留了关系型数据库即时查询的能力，保留了索引（底层是基于B tree）的能力。这一点汲取了关系型数据库的优点，相比于同类型的NoSQL redis 并没有上述的能力。

（3）复制能力

MongoDB自身提供了副本集能将数据分布在多台机器上实现冗余，目的是可以提供自动故障转移、扩展读能力。

（4）速度与持久性

MongoDB的驱动实现一个写入语义 fire and forget ，即通过驱动调用写入时，可以立即得到返回得到成功的结果（即使是报错），这样让写入的速度更加快，当然会有一定的不安全性，完全依赖网络。

MongoDB提供了Journaling日志的概念，实际上像mysql的bin-log日志，当需要插入的时候会先往日志里面写入记录，再完成实际的数据操作，这样如果出现停电，进程突然中断的情况，可以保障数据不会错误，可以通过修复功能读取Journaling日志进行修复。

（5）数据扩展

MongoDB使用分片技术对数据进行扩展，MongoDB能自动分片、自动转移分片里面的数据块，让每一个服务器里面存储的数据都是一样大小。

MongoDB核心服务器主要是通过mongod程序启动的，而且在启动时不需对MongoDB使用的内存进行配置，因为其设计哲学是内存管理最好是交给操作系统，缺少内存配置是MongoDB的设计亮点，另外，还可通过mongos路由服务器使用分片功能。

MongoDB的主要客户端是可以交互的js shell 通过mongo启动，使用js shell能使用js直接与MongoDB进行交流，像使用sql语句查询mysql数据一样使用js语法查询MongoDB的数据，另外还提供了各种语言的驱动包，方便各种语言的接入。

mongodump和mongorestore,备份和恢复数据库的标准工具。输出BSON格式，迁移数据库。

mongoexport和mongoimport，用来导入导出JSON、CSV和TSV数据，数据需要支持多格式时有用。mongoimport还能用与大数据集的初始导入，但是在导入前顺便还要注意一下，为了能充分利用好mongoDB通常需要对数据模型做一些调整。

mongosniff,网络嗅探工具，用来观察发送到数据库的操作。基本就是把网络上传输的BSON转换为易于人们阅读的shell语句。

因此，可以总结得到，MongoDB结合键值存储和关系数据库的最好特性。因为简单，所以数据极快，而且相对容易伸缩还提供复杂查询机制的数据库。MongoDB需要跑在64位的服务器上面，且最好单独部署，因为是数据库，所以也需要对其进行热备、冷备处理。

因为本篇文章不是API手册，所有这里对shell的使用也是基础的介绍什么功能可以用什么语句，主要是为了展示使用MongoDB shell的方便性，如果需要知道具体的MongoDB shell语法可以查阅官方文档。

创建数据库并不是必须的操作，数据库与集合只有在第一次插入文档时才会被创建，与对数据的动态处理方式是一致的。简化并加速开发过程，而且有利于动态分配命名空间。如果担心数据库或集合被意外创建，可以开启严格模式。

以上的命令只是简单实例，假设如果你之前没有学习过任何数据库语法，同时开始学sql查询语法和MongoDB 查询语法，你会发现哪一个更简单呢？如果你使用的是java驱动去操作MongoDB，你会发现任何的查询都像Hibernate提供出来的查询方式一样，只要构建好一个查询条件对象，便能轻松查询（接下来会给出示例），博主之前熟悉ES6，所以入手MongoDB js shell完成没问题，也正因为这样简洁，完善的查询机制，深深的爱上了MongoDB。

使用java驱动链接MongoDB是一件非常简单的事情，简单的引用，简单的做增删改查。在使用完java驱动后我才发现spring 对MongoDB 的封装还不如官方自身提供出来的东西好用，下面简单的展示一下使用。

这里只举例了简单的链接与简单的MongoDB操作，可见其操作的容易性。使用驱动时是基于TCP套接字与MongoDB进行通信的，如果查询结果较多，恰好无法全部放进第一服务器中，将会向服务器发送一个getmore指令获取下一批查询结果。

插入数据到服务器时间，不会等待服务器的响应，驱动会假设写入是成功的，实际是使用客户端生成对象id，但是该行为可以通过配置配置，可以通过安全模式开启，安全模式可以校验服务器端插入的错误。

要清楚了解MongoDB的基本数据单元。在关系型数据库中有带列和行的数据表。而MongoDB数据的基本单元是BSON文档，在键值中有指向不定类型值的键，MongoDB拥有即时查询，但不支持联结操作，简单的键值存储只能根据单个键来获取值，不支持事务，但支持多种原子更新操作。

如读写比是怎样的，需要何种查询，数据是如何更新的，会不会存在什么并发问题，数据结构化的程度是要求高还是低。系统本身的需求决定mysql还是MongoDB。

在关于schema 的设计中要注意一些原则，比如：

数据库是集合的逻辑与物理分组，MongoDB没有提供创建数据库的语法，只有在插入集合时，数据库才开始建立。创建数据库后会在磁盘分配一组数据文件，所有集合、索引和数据库的其他元数据都保存在这些文件中，查阅数据库使用磁盘状态可通过。

集合是结构上或概念上相似得文档的容器，集合的名称可以包含数字、字母或 . 符号，但必须以字母或数字开头，完全。

限定集合名不能超过128个字符，实际上 . 符号在集合中很有用，能提供某种虚拟命名空间，这是一种组织上的原则，和其他集合是一视同仁的。在集合中可以使用。

其次是键值，在MongoDB里面所有的字符串都是UTF-8类型。数字类型包括double、int、long。日期类型都是UTC格式，所以在MongoDB里面看到的时间会比北京时间慢8小时。整个文档大小会限制在16m以内，因为这样可以防止创建难看的数据类型，且小文档可以提升性能，批量插入文档理想数字范围是10~200，大小不能超过16MB。

（1）索引能显著减少获取文档的所需工作量，具体的对比可以通过 .explain()方法进行对比

（2）解析查询时MongoDB通过最优计划选择一个索引进行查询，当没有最适合索引时，会先不同的使用各个索引进行查询，最终选出一个最优索引做查询

（3）如果有一个a-b的复合索引，那么仅针对a的索引是冗余的

（4）复合索引里的键的顺序是很重要的

（1）单键索引

（2）复合索引

（3）唯一性索引

（4）稀疏索引

如索引的字段会出现null的值，或是大量文档都不包含被索引的键。

如果数据集很大时，构建索引将会花费很长的时间，且会影响程序性能，可通过

当使用 mongorestore 时会重新构建索引。当曾经执行过大规模的删除时，可使用

对索引进行压缩，重建。

（1）查阅慢查询日志

（2）分析慢查询

注意新版本的MongoDB 的explain方法是需要参数的，不然只显示普通的信息。

本节同样主要简单呈现MongoDB副本集搭建的简易性，与副本集的强壮性，监控容易性

提供主从复制能力，热备能力，故障转移能力

实际上MongoDB对副本集的操作跟mysql主从操作是差不多的，先看一下mysql的主从数据流动过程

而MongoDB主要依赖的日志文件是oplog

写操作先被记录下来，添加到主节点的oplog里。与此同时，所有从结点复制oplog。首先，查看自己oplog里最后一条的时间戳；其次，查询主节点oplog里所有大于此时间戳的条目;最后，把那些条目添加到自己的oplog里并应用到自己的库里。从节点使用长轮询立即应用来自主结点oplog的新条目。

当遇到以下情况，从节点会停止复制

local数据库保存了所有副本集元素据和oplog日志

可以使用以下命令查看复制情况

每个副本集成员每秒钟ping一次其他所有成员，可以通过rs.status()看到节点上次的心跳检测时间戳和 健康 状况。

这个点没必要过多描述，但是有一个特殊场景，如果从节点和仲裁节点都被杀了，只剩下主节点，他会把自己降级成为从节点。

如果主节点的数据还没有写到从库，那么数据不能算提交，当该主节点变成从节点时，便会触发回滚，那些没写到从库的数据将会被删除，可以通过rollback子目录中的BSON文件恢复回滚的内容。

（1）使用单节点链接

只能链接到主节点，如果链接到从节点的话，会被拒绝写入操作，但是如果没有使用安全模式，因为mongo的fire and forget 特性，会把拒绝写入的异常给吃掉。

（2）使用副本集方式链接

能根据写入的情况自动进行故障转移，但是当副本集进行新的选举时，还是会出现故障，如果不使用安全模式，依旧会出现写不进去，但现实成功的情况。

分片是数据库切分的一个概念实现，这里也是简单总结为什么要使用分片以及分片的原理，操作。

当数据量过大，索引和工作数据集占用的内存就会越来越多，所以需要通过分片负载来解决这个问题

（1）分片组件

（2）分片的核心操作

分片一个集合：分片是根据一个属性的范围进行划分的，MongoDB使用所谓的分片键让每个文档在这些范围里找到自己的位置

块：是位于一个分片中的一段连续的分片键范围，可以理解为若干个块组成分片，分片组成MongoDB的全部数据

（3）拆分与迁移

块的拆分：初始化时只有一个块，达到最大块尺寸64MB或100000个文档就会触发块的拆分。把原来的范围一分为二，这样就有了两个块，每个块都有相同数量的文档。

迁移：当分片中的数据大小不一时会产生迁移的动作，比如分片A的数据比较多，会将分片A里面的一些块转移到分片B里面去。分片集群通过在分片中移动块来实现均衡，是由名为均衡器的软件进程管理的，任务是确保数据在各个分片中保持均匀分布，当集群中拥有块最多的分片与拥有块最少分片的块差大于8时，均衡器就会发起一次均衡处理。

启动两个副本集、三个配置服务器、一个mongos进程

配置分片

（1）分片查询类型

（2）索引

分片集合只允许在_id字段和分片键上添加唯一性索引，其他地方不行，因为这需要在分片间进行通信，实施起来很复杂。

当创建分片时，会根据分片键创建一个索引。

（1）分片键是不可修改的、分片键的选择非常重要

（2）低效的分片键

（3）理想的分片键

（1）部署拓扑

根据不同的数据中心划分

这里写图片描述

（2）最低要求

（3）配置的注意事项

需要估计集群大小，可使用以下命令对现有集合进行分片处理

（4）备份分片集群

备份分片时需要停止均衡器

（1）部署架构

使用64位机器、32位机器会制约mongodb的内存，使其最大值为1.5GB

（2）cpu

mongodb 只有当索引和工作集都可放入内存时，才会遇到CPU瓶颈，CPU在mongodb使用中的作用是用来检索数据，如果看到CPU使用饱和的情况，可以通过查询慢查询日志，排查是不是查询的问题导致的，如果是可以通过添加索引来解决问题

mongodb写入数据时会使用到CPU，但是mongodb写入时间一次只用到一个核，如果有频繁的写入行为，可以通过分片来解决这个问题

（3）内存

大内存是mongodb的保障，如果工作集大小超过内存，将会导致性能下降，因为这将会增加数据加载入内存的动作

（4）硬盘

mongodb默认每60s会与磁盘强制同步一次，称为后台刷新，会产生I/O操作。在重启时mongodb会将磁盘里面的数据加载至内存，高速磁盘将会减少同步的时间

（5）文件系统

使用ext4 和 xfs 文件系统

禁用最后访问时间

（6）文件描述符

linux 默认文件描述符是1024，需要大额度的提升这个额度

（7）时钟

mongodb各个节点服务器之间使用ntp服务器

（1）绑定IP

启动时使用 - -bind_ip 命令

（2）身份验证

启动时使用 - -auth 命令

（3）副本集身份认证

使用keyFile，注意keyFile文件的权限必须是600，不然会启动不起来

（1）拓扑结构

搭建副本集至少需要两个节点，其中仲裁结点不需要有自己的服务器

（2）Journaling日志

写数据时会先写入日志，而此时的数据也不是直接写入硬盘，而是写入内存

但是Journaling日志会消耗内存，所以可以在主库上面关闭，在从库上面启动

可以单独为Journaling日志使用一块固态硬盘

在插入时，可以通过驱动确保Journaling插入后再反馈，但是会非常影响性能。

logpath 选项指定日志存储地址

-vvvvv 选项（v越多，输出越详细）

db.runCommand({logrotare:1}) 开启滚动日志

（1）serverStatus

这里写图片描述

（2）top

（3）db.currentOp()

动态展示mongodb活动数据

占用当前mongodb监听端口往上1000号的端口

（1）mongodump

把数据库内容导出成BSON文件，而mongorestore能读取并还原这些文件

（2）mongorestore

把导出的BSON文件还原到数据库

（3）备份原始数据文件

可以这么做，但是，操作之前需要进行锁库处理 db.runCommand({fsync:1,lock:true})

db.$cmd.sys.unlock.findOne() 请求解锁操作，但是数据库不会立刻解锁，需要使用db.currentOp()验证。

（1）修复

mongd --repair 修复所有数据库

db.runCommand({repairDatabase:1}) 修复单个数据库

修复就是根据Jourling文件读取和重写所有数据文件并重建各个索引

（2）压紧

压紧，会重写数据文件，并重建集合的全部索引，需要停机或者在从库上面运行,如果需要在主库上面运行，需要添加force参数 保证加写锁。

（1）监控磁盘状态

（2）为提升性能检查索引和查询

总的来说，扫描尽可能少的文档。

保证没有冗余的索引，冗余的索引会占用磁盘空间、消耗更多的内存，在每次写入时还需做更多工作

（3）添加内存

dataSize 数据大小 和 indexSize 索引大小，如果两者的和大于内存，那么将会影响性能。

storageSize超过dataSize 数据大小 两倍以上，就会因磁盘碎片而影响性能，需要压缩。

Q4: 【mongoDB】mongoDB的高可用、一致性

高可用是MongoDB最核心的功能之一，相信很多同学也是因为这一特性才想深入了解它的。

那么本节就来说下MongoDB通过哪些方式来实现它的高可用，然后给予这些特性我们可以实现什么程度的高可用。

相信一旦提到高可用，浮现在大家脑海里会有如下几个问题：

那么，带着这些问题，我们继续看下去，看完大家应该会对这些问题有所了解了。

MongoDB高可用的基础是复制集群，复制集群本质来说就是一份数据存多份，保证一台机器挂掉了数据不会丢失。

一个副本集至少有3个节点组成：

从上面的节点类型可以看出，一个三节点的复制集群可能是PSS或者PSA结构。

PSA结构优点是节约成本，但是缺点是Primary挂掉之后，一些依赖 majority（多数）特性的写功能出问题，因此一般不建议使用。

复制集群确保数据一致性的核心设计是：

从上面4点我们可以得出 MongoDB 高可用的如下结论：

MongoDB宕机重启之后可以通过checkpoint快速恢复上一个60s之前的数据。

MongoDB最后一个checkpoint到宕机期间的数据可以通过Journal日志回放恢复。

Journal日志因为是100ms刷盘一次，因此至多会丢失100ms的数据

（这个可以通过WriteConcern的参数控制不丢失，只是性能会受影响，适合可靠性要求非常严格的场景）

如果在写数据开启了多数写，那么就算Primary宕机了也是至多丢失100ms数据（可避免，同上）。

分布式系统必须要面对的一个问题就是数据的一致性和高可用，针对这个问题有一个非常著名的理论就是CAP理论。

CAP理论的核心结论是：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

关于CAP理论在网上有非常多的论述，这里也不赘述。

CAP理论提出了分布式系统必须面临的问题，但是我们也不可能因为这个问题就不用分布式系统。

因此，BASE（Basically Available基本可用、Soft state软状态、Eventually consistent最终一致性）理论被提出来了。

BASE理论是在一致性和可用性上的平衡，现在大部分分布式系统都是基于 BASE理论设计的，当然MongoDB也是遵循此理论的。

MongoDB为了保证可用性和分区容错性，采用的是副本集的方式，这种模式就必须要解决的一个问题就是怎样快速在系统启动和Primary发生异常时选取一个合适的主节点。

这里潜在着多个问题：

MongoDB的选举算法是基于Raft协议的改进，Raft协议将分布式集群里面的节点有3种状态：

leader：就是Primary节点，负责整个集群的写操作。

candidate：候选者，在Primary节点挂掉之后，参与竞选的节点。只有选举期间才会存在，是个临时状态。

follower：就是Secondary节点，被动的从Primary节点拉取更新数据。

节点的状态变化是：正常情况下只有一个leader和多个flower，当leader挂掉了，那么flower里面就会有部分节点成为candidate参与竞选。

当某个candidate竞选成功之后就成为新的leader，而其他candidate回到flower状态。

具体状态机如下：

Raft协议中有两个核心RPC协议分别应用在选举阶段和正常阶段：

请求投票：选举阶段，candidate向其他节点发起请求，请求对方给自己投票。

追加条目：正常阶段，leader节点向follower节点发起请求，告诉对方有数据更新，同时作为心跳机制来向所有follower宣示自己的地位。

如果follower在一定时间内没有收到该请求就会启动新一轮的选举投票。

Raft协议规定了在选举阶段的投票规则：

一个节点，在一个选举周期（Term）内只能给一个candidate节点投赞成票，且先到先得。

只有在candidate节点的oplog领先或和自己相同时才投赞成票。

一轮完整的选举过程包含如下内容：

以上就是目前掌握的MongoDB的选举机制，其中有个问题暂时还未得到解答，就是最后一个，怎样确保选出的Primary是最合适的那一个?

因为，从前面的协议来看，存在一个逻辑bug：由于follower转换成candidate是随机并行的，再加上先到先得的投票机制会导致选出一个次优的节点成为Primary。

针对Raft协议的这个问题，下来查询了一些资料，结论是：

Raft协议确实不保证选举出来的Primary节点是最优的。

MongoDB通过在选举成功，到新Primary即位之前，新增了一个 catchup（追赶）操作来解决。

即在节点获取投票胜利之后，会先检查其它节点是否有比自己更新的oplog，如果没有就直接即位，如果有就先把数据同步过来再即位。

MongoDB的主从同步机制是确保数据一致性和可靠性的重要机制。其同步的基础是oplog，类似MySQL的binlog，但是也有一些差异，oplog虽然叫log但并不是一个文件，而是一个集合（Collection）。

同时由于 oplog 的并行写入，存在尾部乱序和空洞现象，具体来说就是oplog里面的数据顺序可能是和实际数据顺序不一致，并且存在时间的不连续问题。

为了解决这个问题，MongoDB采用的是混合逻辑时钟（HLC）来解决的，HLC不止解决乱序和空洞问题，同时也是用来解决分布式系统上事务一致性的方案。

主从同步的本质实际上就是，Primary节点接收客户端请求，将更新操作写到oplog，然后Secondary从同步源拉取oplog并本地回放，实现数据的同步。

同步源是指节点拉取oplog的源节点，这个节点不一定是Primary，链式复制模式下就可能是任何节点。

节点的同步源选取是一个非常复杂的过程，大致上来说是：

在同步源选取时有些特殊情况：

用户可以为节点指定同步源。

如果关闭链式复制，所有Secondary节点的同步源都是Primary节点。

如果从同步源拉取出错了，会被短期加入黑名单。

整个拉取和回放的逻辑非常复杂，这里根据自己的理解简化说明，如果想了解更多知识可以参考《MongoDB复制技术内幕》

节点有一个专门拉取oplog的线程，通过Exhausted cursor从同步源拉取 oplog。拉取下来之后，并不会执行回放执行，而是会将其丢到一个本地

的阻塞队列中。

然后有多个具体的执行线程，从阻塞队列中取出oplog并执行。

在取出过程中，同一个Collection的oplog一定会被同一个线程取出执行，线程会尽可能的合并连续的插入命令。

整个回放的执行过程，大致为先加锁，然后写本店oplog，然后将oplog刷盘（WAL机制），最后更新自己的最新opTime。

MongoDB全方位知识图谱

mongodb复制集oplog的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于mongodb数据复制、mongodb复制集oplog的信息别忘了在本站进行查找喔。