MongoDB存在18G.wt文件却无法找到对应所属集合该如何排查

该文件的本质 #

这个collection-14--5786157352597922030.wt是WiredTiger存储引擎专属的集合数据存储文件，你在现有集合统计中找不到对应记录，基本可以判定是已删除集合的残留孤儿文件。

为什么删除集合后文件仍存在 #

这类孤儿文件的出现通常对应以下几种场景：

• 之前执行集合/数据库删除操作时，节点刚好发生主备切换、进程异常崩溃，导致磁盘文件回收的逻辑没有执行完成
• 分片集群曾执行过集合分片迁移，迁移完成后源分片的旧集合数据文件没有被正常回收
• 你调整过dropDelayMillis配置项，该配置会让集合删除后延迟指定时间再回收磁盘文件
• 3.6、4.0系列的部分旧版本MongoDB存在已知bug，会出现删除集合后磁盘文件不自动回收的问题

为什么文件修改时间晚于删除操作时间 #

即使集合已经被逻辑删除，只要文件还没有被正式回收，WiredTiger的后台线程在执行例行检查点（checkpoint）、过期快照清理、未使用空间标记等操作时，仍会修改该文件的元数据，导致文件的修改时间持续更新，这个属于正常现象，不代表该文件还在承载活跃的读写请求。

验证&处理方案 #

1. 你可以先连接到该分片节点的Mongo shell，执行以下命令查看是否存在待删除的集合：

// 遍历所有库查看所有集合的ident信息
db.adminCommand({listDatabases:1}).databases.forEach(dbInfo => {
  let db = db.getSiblingDB(dbInfo.name);
  db.getCollectionInfos().forEach(collInfo => {
    print(`库：${dbInfo.name}，集合：${collInfo.name}，ident：${collInfo.id}`);
  })
})

如果输出结果中没有和collection-14匹配的ident，就可以确认是孤儿文件。
2. 保险起见可以在业务低峰期，先将该文件移动到其他磁盘目录，然后重启该分片节点，启动后验证所有集合访问正常、集群状态无报错，就可以直接删除该文件释放18G磁盘空间。如果验证过程中出现异常，把文件移回原目录重启即可恢复。

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