在 MongoDB 中，2540 通常对应 IndexBuildError，表示索引构建任务在完成前被中断。触发这个错误的原因可能包括磁盘空间不足、节点角色切换、进程重启等，但生产环境里最常见的是索引排序临时文件占满 dbPath 所在分区。遇到 2540 时，不能只盯着集合本身的体积，还要重点检查 WiredTiger 在索引构建阶段产生的临时写入量。
一、先定位 2540 错误的具体触发点
2540 错误通常不会单独出现，mongod 日志中会伴随 IndexBuildError、codeName 或 WiredTiger 的底层错误码。查看日志的命令如下：
grep -i "IndexBuild\|2540\|No space" /var/log/mongodb/mongod.log | tail -n 80
如果日志里出现 WiredTiger error (28) 和 No space left on device，基本可以确认是临时文件写入路径的剩余空间不足。此时需要检查自定义的 dbPath 所在分区，而不是只看整个根分区。很多部署会把数据盘挂载到独立目录，根分区空间充足但数据盘已经写满。
除了日志，也可以在 mongo shell 里查看正在运行的索引构建任务：
db.currentOp({
"$or": [
{ "msg": /Index Build/ },
{ "command.createIndexes": { "$exists": true } }
]
}).inprog.forEach(function(op) {
printjson({
opid: op.opid,
ns: op.ns,
msg: op.msg,
secs_running: op.secs_running
});
});
得到 opid 后可以先确认任务所在的命名空间、已运行时长和状态。失败的任务如果仍然挂起，也需要及时清理，避免继续占用连接和排序资源。
二、WiredTiger 索引构建中的临时文件从哪来
MongoDB 使用 WiredTiger 存储引擎时，创建索引并不是简单地把原集合扫描一遍后直接写入索引文件。对于无法完全放进内存排序缓冲区的索引键，WiredTiger 会使用外部排序算法，先把一部分有序数据写入磁盘上的临时文件，再通过归并排序生成最终索引。这个过程中磁盘写入量可能接近甚至超过集合中需要排序的键大小。
临时文件通常位于 dbPath 当前目录下，并带有 _tmp 或类似后缀。注意，即使你配置了 directoryForIndexes，常规索引文件可以拆到子目录，但构建过程中的排序临时文件仍然依赖 dbPath 所在卷的可用空间，不能用该参数把临时空间单独拆走。
可以通过配置文件限制单个索引构建使用的内存，从而影响临时文件的落盘比例：
setParameter: maxIndexBuildMemoryUsageMegabytes: 256
这个参数并不直接解决磁盘不足的问题。如果调大，索引构建会尽量使用内存，减少临时文件写入；如果调小，则会写出更多临时文件，但内存压力更小。生产环境建议根据实例内存大小和索引字段大小调整，避免为了降低磁盘占用而触发 OOM。
三、释放空间并恢复索引构建
先在操作系统层面确认哪些目录占用了 dbPath 所在分区的空间。可以使用下面的命令快速查看 dbPath 一级目录的体积：
du -sh /var/lib/mongodb/* | sort -rh | head -n 20
如果怀疑存在历史失败残留的临时文件，建议在停止 mongod 或确认没有活动索引构建后，再对 _tmp 类文件进行清理。清理前务必保留 WiredTiger 的元数据文件，例如 WiredTiger.wt、WiredTiger 文件等，只处理与索引构建相关的临时文件。
如果数据盘本身空间不足，临时清理只能争取时间，最终还是要迁移 dbPath 或扩容磁盘。迁移时先停库，再使用 rsync 保留权限和所有权，修改配置文件后重新启动：
sudo systemctl stop mongod sudo rsync -av /var/lib/mongodb/ /data/mongodb/ sudo chown -R mongodb:mongodb /data/mongodb # 修改 mongod.conf 中的 storage.dbPath 后启动 sudo systemctl start mongod
对于副本集，可以优先在从节点上创建索引，完成后再切换主节点，避免主节点在业务高峰同时承担读写和索引排序压力。使用 createIndexes 时也可以分批次创建多个索引，避免一次构建多个大索引导致临时文件同时写满磁盘。
已经失败的索引任务需要再次执行前，先确认磁盘可用空间至少大于预期索引大小的 1.5 倍。对于大集合，建议在低峰期执行，并打开 db.currentOp() 监控索引构建是否持续占用磁盘。
四、配置空间告警与提前预防
2540 错误往往在磁盘完全写满前就已经开始影响 MongoDB。WiredTiger 的写入缓冲、日志文件和临时文件共享同一个 dbPath 分区的空间，因此空间不足不仅会导致索引构建失败，还可能导致写入阻塞甚至实例不可用。运维上应该对 dbPath 所在挂载点设置阈值告警，例如使用率超过 70% 就提示，超过 85% 就禁止新建大索引。
可以在计划任务中加入简单的磁盘检查脚本：
#!/bin/bash
USAGE=$(df /var/lib/mongodb | awk 'NR==2 {gsub("%","",$5); print $5}')
if [ "$USAGE" -gt 85 ]; then
echo "MongoDB dbPath usage above 85%" | mail -s "mongodb disk warning" admin@ipipp.com
fi
在索引构建期间，也可以通过 du -sh 间隔观察临时文件变化，同时结合 db.currentOp() 查看索引构建的内存和进度。如果发现磁盘空间下降速度过快，应主动停止索引任务，清理排序数据，然后选择更大空间的窗口再执行。
最后需要明确一点：单纯扩容磁盘并不能避免所有 2540 错误。索引字段过大、索引过多、集合文档键过长或内存参数设置不合理，都可能导致临时文件异常膨胀。只有把存储空间、内存上限、索引数量和构建时间窗口一起规划，才能让索引构建稳定完成。
MongoDB错误码2540索引构建临时文件磁盘空间不足修改时间：2026-09-19 22:27:29