MongoDB在启动过程中若无法找到WiredTiger引擎所需的事务日志，便会抛出错误码1040并直接退出进程。该问题在自托管环境里并不罕见，多数情况与文件系统的非正常操作有关。理解其背后的存储机制，才能选择正确的处理路径。
一、故障原理与触发场景
MongoDB从3.2版本起默认使用WiredTiger作为存储引擎，它依赖data/db/journal目录下的日志文件保证崩溃一致性。每当有写操作时，引擎先追加记录到journal，再异步刷入数据文件。如果实例在关闭前没来得及做checkpoint，而journal又被外部删除，下次启动就会因找不到最后一个有效日志段而报1040。
常见触发原因包括运维人员清理磁盘时误删整个journal文件夹、底层存储卷突然只读导致日志写入失败、以及容器编排中volume挂载异常使目录为空。还有一种隐蔽情况是文件系统损坏，ls能看到文件但读取返回IO错误，MongoDB校验头信息不匹配同样归为1040。
1.1 错误日志特征
在mongod.log中通常能看到类似描述：WiredTiger error (0) encountered when opening journal files，随后紧跟exception in initAndListen: 1040。这时进程状态码为非0，systemd会不断重启又失败。
通过以下命令可快速确认是否为日志缺失而非权限问题：
# 查看journal目录内容 ls -la /var/lib/mongodb/journal/ # 若输出为空或提示No such file or directory，则基本锁定1040诱因
二、紧急恢复操作步骤
发现1040后第一原则是不能盲目重启，应先备份当前data目录快照，防止修复动作破坏残留数据。接着尝试让MongoDB自行修复，大多数轻量丢失可被纠正。
使用自带repair模式启动，该过程会扫描数据文件并重建缺失的元数据与日志。注意repair需要额外磁盘空间，约为现有数据的一点五倍。执行指令如下：
# 停止服务 systemctl stop mongod # 备份原目录 cp -r /var/lib/mongodb /var/lib/mongodb_bak # 运行修复 mongod --dbpath /var/lib/mongodb --repair # 修复后改回权限并启动 chown -R mongodb:mongodb /var/lib/mongodb systemctl start mongod
2.1 修复失败时的备份恢复
如果journal段已被物理清除，repair会报告cannot find journal file且退出。此时只能从冷备份还原：将上次全量备份的data目录覆盖回去，再应用备份时间点之后的oplog。示例用mongorestore配合oplog重放：
# 假定全备解压到 /restore/mongodb_full rm -rf /var/lib/mongodb cp -r /restore/mongodb_full /var/lib/mongodb chown -R mongodb:mongodb /var/lib/mongodb # 启动后通过mongosh注入oplog mongorestore --oplogReplay /restore/oplog_dump
这种方法虽能找回绝大部分数据，但备份间隙的写入若没进oplog就会丢失。因此备份频率与oplog窗口必须按业务容忍度设定。
三、长期预防方案
治本的办法是从部署架构上降低日志丢失概率。首先应在配置文件显式开启日志，并把它放到独立的高可用磁盘。
修改mongod.conf片段如下，确保storage.journal.enabled不被误关：
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
commitIntervalMs: 100
3.1 监控与告警
写一个简单的定时脚本，检查journal目录inode数，一旦低于阈值就触发告警，可比业务报错更早发现问题。下面是用bash实现的雏形：
#!/bin/bash count=$(ls /var/lib/mongodb/journal/ 2>/dev/null | wc -l) if [ "$count" -lt 1 ]; then echo "journal missing" | mail -s "mongo alert" admin@ipipp.com fi
此外，容器环境务必给volume设置readonly=false且定期scrub，避免静默损坏。配合MongoDB Atlas或Ops Manager的连续备份，可将RPO压缩到秒级，即使遇到1040也能一键回滚。
四、常见误区澄清
有人以为删除journal后靠--nojournal参数启动就能跳过报错，实际上该参数在新版本已被废弃，强行改源码编译也会破坏WiredTiger恢复协议，导致数据文件状态不一致。正确思路永远是修复或还原，而不是绕过日志。
另一个误区是认为副本集的从节点可以随便清journal，因为主节点会重发操作。事实上从节点本地journal同样参与回放落盘，丢失后仍需走全量同步，反而增加主节点压力。保持每个成员日志完整，集群才真正高可用。