看起来你遇到了MongoDB数据丢失的棘手问题，结合你描述的场景，我来帮你拆解可能的原因和对应的排查、恢复步骤：

一、先定位核心问题：mongod关闭时的异常行为 #

你用kill $(pidof mongod)关闭mongod，虽然默认kill发送的是SIGTERM信号（理论上mongod会优雅关闭，将内存中的脏数据刷到磁盘），但如果当时mongod正处于高负载状态、或者有大量未完成的写入操作，可能会出现部分数据未持久化甚至数据文件损坏的情况。另外，也有可能你kill的mongod实例和你以为的不是同一个——即使你确认了.zsh_history的dbpath，还是得从日志里实锤。

1. 优先查看mongod日志，找关键线索 #

如果启动mongod时没有指定--logpath，日志会输出到终端，但iTerm窗口已经关闭，你可以通过macOS系统日志回溯：

log show --predicate 'process == "mongod"' --last 24h

在日志里找这几个关键信息：

• 启动时的dbpath记录（比如dbpath=/Users/xxx/./db），确认之前运行的mongod确实用的是你现在的目录
• 关闭时的日志，是否有shutdown: going to close listening sockets、shutdown: waiting for fs preallocator这类优雅关闭的提示，还是有aborted、error等异常信息
• 重启时的恢复日志，是否有replaying journal的记录，以及恢复过程中是否有报错

二、尝试恢复数据的具体步骤 #

1. 检查目标db目录的文件完整性 #

进入你的./db目录，确认里面的文件结构：正常的WiredTiger存储引擎应该包含*.wt数据文件、mongod.lock、diagnostic.data文件夹、journal文件夹。如果某些*.wt文件缺失或大小异常，大概率是数据损坏了。

2. 尝试MongoDB内置的修复工具 #

MongoDB提供了修复命令来修复损坏的数据文件，但注意：修复过程可能会丢失部分损坏的数据，建议先备份原db目录再操作：

# 先备份原数据目录
cp -r ./db ./db_backup
# 执行修复
mongod --dbpath ./db --repair

或者用临时修复目录，避免修改原文件：

mongod --dbpath ./db --repairpath ./db_repaired

修复完成后，尝试用修复后的目录启动mongod，检查数据是否恢复：

mongod --dbpath ./db_repaired

3. 检查journal日志的自动恢复 #

如果./db/journal目录存在，mongod重启时会自动重放journal里的操作来恢复数据。但如果journal文件损坏，可能会导致恢复失败。你可以尝试删除journal目录（风险较高，谨慎操作），然后重启mongod，看是否能启动并找回部分数据：

# 先备份journal目录
cp -r ./db/journal ./journal_backup
# 删除journal目录
rm -rf ./db/journal
# 重启mongod
mongod --dbpath ./db

4. 借助系统备份（Time Machine） #

如果你开启了macOS的Time Machine，大概率它已经自动备份了你的./db目录。打开Time Machine，找到./db目录的历史版本（比如升级iTerm2之前的版本），尝试恢复这个备份目录，然后启动mongod查看数据。

三、后续预防措施，避免再踩坑 #

• 用正确的方式关闭mongod：不要直接kill进程，而是用优雅关闭命令：

  # 方式1：通过命令行指定dbpath关闭
  mongod --dbpath ./db --shutdown
  # 方式2：进入mongo shell关闭
  mongo --eval "db.shutdownServer()"
  

• 启动mongod时指定日志文件：这样即使终端关闭，日志也能保留，方便排查问题：

  mongod --dbpath ./db --logpath ./mongod.log --fork
  

• 定期备份数据：用mongodump定期导出数据，或者开启MongoDB的副本集（本地也可以搭单节点副本集）来提高数据安全性：

  mongodump --dbpath ./db --out ./mongodb_backup_$(date +%Y%m%d)
  

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