在腾讯云MongoDB的运营过程中，发现较多用户对副本集主从复制流程的理解还有些偏差。这些偏差在一定程度上影响了应用程序设计和平时的运营。

 

本文会聚焦下面几个问题：

 

写大多数节点是如何完成的？

从节点拉取oplog和回放oplog是否会有阻塞，如何调优？

Mongo Shell 上执行 printSlaveReplicationInfo 命令看主从延迟，系统压力不大时也在秒级，是否正常？

printSlaveReplicationInfo 为什么不能优化到毫秒级别？

在从节点上执行 printSlaveReplicationInfo 命令，发现从节点的数据领先主节点，是否正常？

什么是链式复制？哪些场景适合开启，哪些不适合？

主从复制架构分析

主从复制大致流程

MongoDB副本集模式下，用户向主节点写入数据，并记录oplog. 从节点通过oplog进行数据同步，最终保证副本集中的各个节点的数据一致性。

 

客户端可以指定写入请求的一致性级别（WriteConcern），比如对于数据一致性较高的场景，可以设置数据复制到“大多数”节点才返回成功。这样能够保证即使主节点重启后不会回滚掉之前写入的数据。

 

一个常见的误解：写大多数节点模型下，客户端需要将数据发到多个节点，是否会增加客户端的负担？

 

“写大多数”请求的流程如下，客户端只需要向主节点写入数据即可（不需也不能向从节点直接写数据）；从节点进行oplog同步之后，会将自身已经同步的oplog时间点通知给主节点；主节点维护了副本集中各个从节点的oplog同步情况，如果确定数据已经到了大多数节点上（包括自己），则给客户端返回成功。如果数据同步发生了异常，或者同步太慢，则可能触发超时。

 

同理，ReadConcern Majority也不是客户端去读多个节点，这里不详细讨论

 

 

副本集数据同步示意图

详细的主从同步流程如下图所示（以 1 Primary 1 Secondary 为例）：

 

 

主从复制细节

主要步骤如下：

 

主节点接受用户的写请求，更新用户表和oplog表。如果用户设置了 writeConcern:majority，此时由于不符合写入成功的返回条件，处理线程会阻塞

从节点上的 "rsBackgroundSync" 后台线程通过 find/getmore 命令到主节点上获取oplog，并放入到 OplogBuffer中；"replBatcher" 线程感知到OplogBuffer中的数据并消费，保存到OpQueue中；"OplogApplier" 线程感知OpQueue中的新数据，通过多个（默认16个）worker线程回放Oplog，并更新lastAppliedOpTime 和 lastDurableOpTime

从节点上的 "SyncSourceFeedback" 后台线程感知到有新数据写入成功，将自身最新的 lastAppliedOpTime和lastDurableOpTime 等信息通过 "replSetUpdatePosition" 内部命令返回给主节点

主节点接受到各个从节点 最新的 lastAppliedOpTime 和 lastDurableOpTime（writeConcernMajorityJournalDefault 配置项决定了具体以哪个时间为准），计算大多数节点（包括自己）当前的数据同步进展，并更新 lastCommittedOpTime, 然后唤醒正在等待的请求处理线程

主节点上的用户处理线程给用户返回处理结果

常见误解说明：

误解1：从节点拉取 oplog 回放完之后，才会拉取下一批 oplog

真实情况：拉取和回放属于不同的线程，相互不会阻塞

误解2：对参数 replBatchLimitBytes(默认100MB) 和 replBatchLimitOperations(默认5000) 存在误解，认为回放线程必须累积到这么多oplog后才会批量回放

真实情况：回放线程尽量累积大量数据才回放（批量并发执行效率高）。但是如果oplog比较少，会提前返回。但是极端情况下，可能会有最多阻塞1秒的情况（具体参考 sync_tail.cpp 中的 SyncTail::tryPopAndWaitForMore实现）。关于这一点，下一篇文章会结合代码和例子进行详细分析

误解3：从节点通过心跳返回同步进度，主节点根据心跳信息决定 writeConcern:majority 是否返回

真实情况：从节点通过 replSetUpdatePosition 及时上报同步情况。心跳周期太长，默认 2 秒一次，所以根据心跳信息显然是不合适的

 

性能调优建议

根据实际情况，调整回放线程的个数，默认 16 个。对应 replWriterThreadCount  参数，可在程序启动时指定。

根据实际情况，调整批量回放的最大 oplog 条数（默认 5000）和最大 oplog 大小（默认 100MB）。前者对应 replBatchLimitOperations 参数，可在程序启动时或者运行过程中指定；后者对应 replBatchLimitBytes 参数，在 官方文档中说明可以动态修改，但是实测发现并不成功，代码中也没有找到修改的接口。如果有变更需求，可以直接修改 sync_tail.h 中 replBatchLimitBytes 的初始化代码

主从延迟命令解析

MongoDB 管理员使用 printSlaveReplicationInfo 命令来观察主从延迟情况

 

printSlaveReplicationInfo 是 MongoShell 封装的 js 命令，可以在任意一个MongoShell客户端上直接执行db.printSlaveReplicationInfo 查看 js 源代码。如下所示：

 

function () {

        var startOptimeDate = null; // 基准optime

        var primary = null;

 

        // 根据基准optime，打印节点的延迟情况，精确到秒

        function getReplLag(st) {

            assert(startOptimeDate, "how could this be null (getReplLag startOptimeDate)");

            print("\tsyncedTo: " + st.toString());

            var ago = (startOptimeDate - st) / 1000;

            var hrs = Math.round(ago / 36) / 100;

            var suffix = "";

            if (primary) {

                suffix = "primary ";

            } else {

                suffix = "freshest member (no primary available at the moment)";

            }

            print("\t" + Math.round(ago) + " secs (" + hrs + " hrs) behind the " + suffix);

        }

 

        function getMaster(members) {

            for (i in members) {

                var row = members[i];

                if (row.state === 1) {

                    return row;

                }

            }

 

            return null;

        }

 

        function g(x) {

            assert(x, "how could this be null (printSlaveReplicationInfo gx)");

            print("source: " + x.host);

            if (x.syncedTo) {

                var st = new Date(DB.tsToSeconds(x.syncedTo) * 1000);

                getReplLag(st);

            } else {

                print("\tdoing initial sync");

            }

        }

 

        function r(x) {

            assert(x, "how could this be null (printSlaveReplicationInfo rx)");

            if (x.state == 1 || x.state == 7) {  // ignore primaries (1) and arbiters (7)

                return;

            }

 

            print("source: " + x.name);

            if (x.optime) {

                getReplLag(x.optimeDate);

            } else {

                print("\tno replication info, yet.  State: " + x.stateStr);

            }

        }

 

        var L = this.getSiblingDB("local");

 

        if (L.system.replset.count() != 0) {

            var status = this.adminCommand({'replSetGetStatus': 1}); // replSetGetStatus命令的结果，作为本次计算的数据源

            primary = getMaster(status.members);

            if (primary) {

                startOptimeDate = primary.optimeDate;  //如果主节点存在，则选择主节点的 optime 为基准 optime

            }

            // no primary, find the most recent op among all members

            else {

                startOptimeDate = new Date(0, 0);

                for (i in status.members) { // 如果主节点不存在，则选择最新的 optime 为基准 optime

                    if (status.members[i].optimeDate > startOptimeDate) {

                        startOptimeDate = status.members[i].optimeDate;

                    }

                }

            }

 

            for (i in status.members) { //对除 primary 和 arbiter 的节点，打印延迟情况

                r(status.members[i]);

            }

        }

    }

总体来说，根据replSetGetStatus命令中每个 member 的 optimeDate 来计算延迟。分析内核代码发现， replSetGetStatus 命令通过心跳信息来获取其他节点的 optimeDate。

 

可以得出，printSlaveReplicationInfo 命令的结果依赖于心跳信息。

 

 

MongoDB副本集心跳示意图

默认配置下，节点之间的心跳间隔是 2 秒，也就是说printSlaveReplicationInfo展示的可能是“过期”信息，存在一定的误差。

 

比如有一个持续被写入的副本集，主节点在 t1 时刻维护的还是 t0 时刻的心跳信息，则 printSlaveReplicationInfo 命令会显示从节点比主节点落后 1 秒，在主节点很快接受到从节点更新的信息之后，主从延迟又会马上变为 0 秒。出现主从延迟“抖动”的情况。

 

同理，按照从节点的视角来看，在 t1 时刻已经从主节点同步到了最新的数据，但是维护的主节点心跳还是 t0 时刻的“过期”数据。此时会认为主节点的 optimeDate 还是 t0，所以在从节点上执行 printSlaveReplicationInfo 命令，会看到从节点“领先”主节点 1 秒的奇怪现象。

 

特殊说明

心跳信息维护在  TopologyCoordinator::memberData 中

内核对主节点维护的 memberData 进行了优化：除了正常的心跳请求会更新之外，从节点发送过来的 replSetUpdatePosition 也会更新 memberData 中的数据。所以在主节点上执行 printSlaveReplicationInfo 命令 相对来说 已经尽量做到准确了。

 

总结：心跳信息带来的不确定性，会导致 printSlaveReplicationInfo 的结果存在误差

 

延迟命令的精度问题

MongoDB 使用了 BSON 格式的 TimeStamp，是一个 64 bit 的值：

 

高 32 bit 存放 UNIX 秒级时间

低 32 bit 存放 一个递增的计数器，来区分这一秒内的多条oplog

因此，TimeStamp 能够表示的精度只有秒级。

 

因此，printSlaveReplicationInfo 命令看到的秒级延迟不能说明主从延迟真的是秒级。除了前文说到的心跳原因，TimeStamp 的精度问题也会给观测带来误差。

 

链式复制

什么是链式复制

在MongoDB副本集模式中，从节点除了可以到主节点同步数据外，还可以到数据较新的另外一个从节点同步数据。

 

如下图所示，第2个从节点可以切换同步源到第1个从节点，这样副本集的同步关系变成了Primary1-->Secondary1-->Secondary2 链式结构

 

 

image.png

如何开启

通过 rs.reconfig() 命令将 settings.chainingAllowed设置为true（默认已经开启）

根据具体的使用场景，可以在从节点上执行 rs.syncFrom 命令指定同步源。如果不手动指定，则MongoDB后台线程会根据各个节点的 oplog 时间进行选择和切换。

适合开启链式复制的场景

链式复制带来的好处是：不用所有从节点都到主节点同步数据，可以有效减少主节点的压力。

 

对于写完主节点即返回，并读主节点的业务来说，开启链式复制能在一定程度上提升性能。

 

适合关闭链式复制的场景

链式复制带来的缺陷是：

 

数据复制的链路变长。对于 WriteConcern 设置比较大的请求，处理时长会变长。

读oplog的压力从主节点转移到了部分从节点上，会一定程度上影响从节点的性能。

因此，对于 {WriteConcern：majority} 的业务场景，建议关闭链式复制；对于写主读从的业务场景，可以根据实际的请求量，考虑是否关闭链式复制。