Node.js向MongoDB批量导入6000万条数据时出现MongoNetworkError连接关闭问题

• 连接配置完全不符合驱动参数规范，保活机制失效
  你在连接配置里把keepAlive赋值为300000，但MongoDB驱动的keepAlive是布尔类型开关，传入数值不会生效，长连接TCP层面完全没有保活机制，闲置连接会被MongoDB服务端的超时清理策略主动断开；同时你设置的poolSize:1000远超过本地单节点MongoDB的实际承载能力（单节点写入场景下20个连接就能打满磁盘IO），大量闲置连接被服务端关闭时，客户端没有对应的错误处理，就会抛出connection x closed的网络错误。
• 写入逻辑存在严重漏洞，请求完全无限流导致连接被打满
  你代码里的批量判断分支if (numlines >= 80000)中的Promise.all(promises)，实际上从来没有把任何数据库操作的Promise push进promises数组，等于promises永远是空数组，Promise.all永远会立刻resolve，根本起不到批量限流、等待所有请求完成的作用。实际运行时每读到一行数据，就立刻发起一次findOne查询、紧接着发起一次updateOne/insertOne，瞬间发起数万级别的并发请求，把连接池占满，大量请求排队等待，连接长期被占用，最终被服务端强制断开。
• 代码逻辑混乱引发连接非正常关闭
  首先Node.js运行环境没有浏览器端的localStorageAPI，你调用localStorage.setItem的代码如果触发会直接抛错，导致异步流程中断，连接处于半开状态被服务端清理。其次在async.waterfall的插入分支里，你在insertOne的回调里直接调用client.close()，每插入一条新数据就会关闭整个客户端连接，后续所有请求都会触发连接不存在的错误。另外你写的updateOne调用没有加await、也没有传回调，实际是Fire-and-Forget模式，请求没有被纳入流程等待，资源泄露极其严重。
• 无任何网络容错与重连机制
  连接被服务端断开后，你没有做自动重新建立连接、失败请求重试的逻辑，直接把底层Socket的错误抛成业务层异常，导致脚本中断。

千万级数据导入的核心原则是：减少请求次数、控制并发、做好断点续传，不要追求高并发打满数据库

1. 修正连接模块的配置 #

把原来的错误连接配置替换为符合驱动规范的参数：

const option = {
    useUnifiedTopology: true,
    useNewUrlParser: true,
    // 单节点导入场景，20个最大连接足够打满磁盘IO，远低于1000的无效配置
    maxPoolSize: 20,
    minPoolSize: 2,
    // 正确开启TCP保活，避免闲置连接被服务端清理
    keepAlive: true,
    keepAliveInitialDelay: 30000,
    connectTimeoutMS: 30000,
    socketTimeoutMS: 0, // 长写入操作不设置超时，避免被主动断开
    retryWrites: true, // 开启驱动内置的写重试
    serverSelectionTimeoutMS: 30000,
};

关键注意点：

• 整个导入流程中不要随意调用client.close()，只在所有文件处理完成、进度保存后统一关闭连接
• 废弃旧版的poolSize配置参数，使用统一拓扑下的maxPoolSize参数

2. 重写写入逻辑，替代逐行操作的低效模式 #

逐行findOne判断存在性再插入/更新的模式，是6000万级数据导入最大的性能瓶颈，请求量会达到1.2亿次以上，数据库根本扛不住。
修正后的写入流程：

• 读取文件时维持1000条数据的批量缓冲区，每攒满1000条就做一次批量处理
• 用bulkWrite实现幂等写入：给每条数据生成带upsert:true的updateOne操作，一次性提交给数据库，原来的1000次单请求（1000次find + 1000次write）压缩为1次批量请求，性能提升两个数量级
• 删掉所有浏览器端localStorage的调用，改用本地JSON文件记录每个文件已经处理的行号，实现断点续传——遇到报错中断后，下次启动从上次的进度位置继续，不需要从头导入
• 给所有数据库操作加幂等重试逻辑：遇到临时网络错误、连接断开时，延迟1秒后自动重试最多5次，不直接抛出崩溃

3. 导入前的优化准备 #

• 提前给sku字段创建唯一索引，保证upsert操作的性能，同时避免重复数据写入
• 临时关闭集合的其他非必要索引，等全量导入完成后再构建，大幅降低写入时的IO开销
• 调整MongoDB的日志级别为warning级别，避免大量访问日志占用磁盘IO

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