K8s环境下意外关机后单机MongoDB如何恢复运行？

前置操作（所有修复动作前必须做） #

• 第一时间对MongoDB挂载的持久化数据目录、日志目录做全量冷拷贝备份，所有后续修复操作都在备份副本上验证没问题再碰生产数据，避免二次损坏导致数据完全不可恢复。
• 不要在未拿到错误日志的情况下盲目执行修复命令，先通过命令kubectl logs -n <MongoDB所在命名空间> <故障Pod名称> --previous拉取Pod上一次崩溃前的运行日志，重点筛选wt、corruption、recovery、fatal assertion、lock关键词，定位具体错误点。如果--previous参数拿不到日志，直接进入持久卷的挂载路径，找到mongod.log文件查看最新报错。

常见故障对应处理方案 #

1. 文件权限异常 #

断电后存储挂载点文件属主错乱是高频非数据损坏类故障，优先排查：

• 进入Pod或登录对应持久卷的宿主目录，执行ls -l <MongoDB数据目录路径>查看文件属主，官方MongoDB镜像默认运行用户UID为999，如果属主变成root或其他用户，直接执行chown -R 999:999 <数据目录路径>修正权限，重启Pod验证是否能正常启动。

2. 非正常关闭导致的锁残留、WAL日志未重放 #

如果日志中出现unclean shutdown detected、WiredTiger lock file exists类报错：

• 确认mongod进程已经完全退出，删除数据目录下的mongod.lock文件，严禁进程运行时删除该文件。
• 执行修复命令重放WiredTiger预写日志完成checkpoint恢复：mongod --dbpath <你的MongoDB数据目录路径> --repair，等待进程自动执行完恢复流程，耗时和数据量正相关，中途不要强制终止进程。修复完成后正常重启Pod即可。

3. 存储引擎数据文件损坏 #

如果日志明确报checksum mismatch、data file corrupted、wt page read failed类数据校验错误：

• 若为副本集部署节点：直接清空该故障节点的数据目录，重启Pod即可，节点会自动从副本集内其他健康节点拉取全量数据同步，同步完成后自动加入集群，该方案无数据丢失风险，是副本集场景的首选恢复方式。
• 若为单节点无副本部署：使用前置步骤做的冷备份数据，执行mongod --dbpath <备份数据目录路径> --repair --repairpath <独立空目录作为修复临时存储路径>做深度修复，修复完成后用生成的有效数据文件替换原故障目录文件，再启动进程。启动后需要逐库逐表执行db.<集合名>.validate()做数据校验，深度修复可能会丢失部分损坏的文档数据。
• 若深度修复失败，直接使用最近一次的全量备份恢复数据，如有oplog备份可重放oplog追平到断电前的时间点。

修复后校验 #

• 服务启动后执行db.serverStatus().wiredTiger确认存储引擎运行状态无异常，副本集场景执行rs.status()确认所有节点状态健康、主从选举正常。
• 对核心业务集合执行数据校验，确认索引、文档无损坏缺失。
• 调整K8s中MongoDB工作负载的terminationGracePeriodSeconds参数到30秒以上，给mongod进程预留足够的刷盘、正常关服时间，降低后续异常掉电的数据损坏概率。

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