如何在不锁定整个mongod实例的情况下复制MongoDB集合？

我来给你几个可行的方案，都是不需要锁定整个MongoDB实例的，针对你的10GB集合场景应该都适用：

方案1：使用聚合管道的$merge操作（MongoDB 4.2+） #

这是我比较推荐的轻量方案，$merge操作会逐文档处理源集合的数据，只会在单个文档级别加锁，完全不会阻塞实例的其他操作，而且可以直接在Mongo Shell里执行，不需要额外工具。

操作步骤： #

1. 连接到MongoDB实例，切换到源数据库：

   use sourceDB
   

2. 执行聚合管道完成全量复制：

   db.sourceCollection.aggregate([
     { $match: {} }, // 空的$match表示复制整个集合，如需过滤数据可添加条件
     { $merge: {
         into: { db: "targetDB", coll: "targetCollection" }, // 指定目标库和集合
         whenMatched: "replace", // 如果目标集合已有相同_id的文档，替换它（可选其他策略）
         whenNotMatched: "insert" // 没有匹配的文档就插入
       }
     }
   ])
   

优缺点： #

• ✅ 无全局锁，仅文档级锁，业务不受影响
• ✅ 可以边复制边做数据转换（比如加字段、过滤数据）
• ✅ 无需额外磁盘空间存储备份文件
• ❌ 如果复制期间源集合有写入，可能会导致目标集合数据和源集合有微小差异（如果需要强一致性，可以结合事务或者在低峰期执行）

方案2：使用mongodump + mongorestore（WiredTiger引擎） #

如果你的MongoDB用的是默认的WiredTiger引擎（3.2+版本默认），mongodump会使用快照读，不会加全局锁，只会有极短时间的表级锁，基本不影响业务。配合--oplog参数还能保证备份期间的写入也被同步，确保数据一致性。

操作步骤： #

1. 执行mongodump备份源集合，同时捕获备份期间的操作日志：

   mongodump --db sourceDB --collection sourceCollection --oplog --out /tmp/mongo_backup
   

   这里--oplog会生成一个包含备份期间所有写入操作的oplog.bson文件，用来保证数据一致性。
2. 将备份恢复到目标数据库：

   mongorestore --db targetDB --collection targetCollection /tmp/mongo_backup/sourceDB/sourceCollection.bson --oplogReplay
   

   --oplogReplay会把备份期间的写入操作应用到目标集合，保证最终数据和源集合完全一致。

优缺点： #

• ✅ WiredTiger下无全局锁，对业务影响极小
• ✅ 能保证数据强一致性
• ❌ 需要额外磁盘空间存储备份文件（10GB集合至少需要10GB临时空间）
• ❌ 步骤比聚合管道多，需要用到命令行工具

方案3：利用副本集Secondary节点操作（副本集架构专属） #

如果你的MongoDB是副本集部署，这是最优解——直接在Secondary节点上执行复制操作，完全不会影响Primary节点的业务。Secondary节点默认是只读的，操作时只会占用Secondary的资源，不会干扰主节点的读写。

操作步骤： #

1. 连接到Secondary节点（注意不要连接Primary）：

   mongo --host secondary-node-ip:port
   

2. 选择上面的方案1（聚合$merge）或者方案2（mongodump/mongorestore）执行即可。

优缺点： #

• ✅ 完全不影响Primary节点的业务，零干扰
• ✅ 可以利用Secondary节点的资源完成复制，不占用主节点CPU/内存
• ❌ 仅适用于副本集架构，单实例无法使用

方案4：Change Streams全量+增量同步 #

如果复制期间源集合有大量写入，或者需要长期保持两个集合同步，可以先用全量复制，再通过Change Streams监听源集合的变更，实时同步到目标集合。

操作步骤： #

1. 先执行一次全量复制（用方案1或方案2），记录复制完成时的操作时间戳：

   const lastOpTime = db.runCommand({ getLastError: 1 }).lastOpTime;
   

2. 开启Change Streams监听源集合的变更，并同步到目标集合：

   const changeStream = db.sourceCollection.watch([], { startAtOperationTime: lastOpTime });
   changeStream.on('change', (change) => {
     const targetColl = db.getSiblingDB('targetDB').targetCollection;
     switch(change.operationType) {
       case 'insert':
         targetColl.insertOne(change.fullDocument);
         break;
       case 'update':
         targetColl.updateOne(
           { _id: change.documentKey._id },
           { $set: change.updateDescription.updateFields }
         );
         break;
       case 'delete':
         targetColl.deleteOne({ _id: change.documentKey._id });
         break;
       case 'replace':
         targetColl.replaceOne({ _id: change.documentKey._id }, change.fullDocument);
         break;
     }
   });
   

优缺点： #

• ✅ 可以实现实时同步，复制期间的写入也不会丢失
• ✅ 无全局锁，业务不受影响
• ❌ 需要编写脚本，复杂度较高，适合有开发能力的团队
• ❌ 需要持续运行脚本，直到复制完成（或长期同步）

注意事项 #

• 确认你的MongoDB引擎是WiredTiger：如果是老的MMAPv1引擎，mongodump会加全局锁，这种情况下优先用聚合$merge方案。
• 复制前建议在低峰期测试，观察系统性能，避免影响业务。
• 如果需要强一致性，根据场景选择对应的方案（比如方案2的--oplog，或者方案4的Change Streams）。

内容的提问来源于stack exchange，提问作者viren