Docker中运行MongoDB使用mongorestore恢复数据卡住如何解决

1. 优先校验备份文件有效性 #

• 进入容器后先执行gzip -t filename.gz做压缩包完整性校验，命令无任何输出才代表压缩包结构正常，返回报错即说明文件损坏、传输截断，需重新获取完整备份。
• 执行ls -lh filename.gz确认文件大小和源备份文件一致，避免挂载目录权限问题导致读到空文件、残缺文件。

2. 核对备份与恢复命令的参数匹配逻辑 #

• 若生成备份时的mongodump命令只加了--gzip、没有加--archive参数，恢复时用--archive=xxx读取会直接卡在解析阶段无任何输出。这种非归档模式的gzip备份，恢复时要去掉--archive参数，指向备份文件所在目录执行：

  mongorestore --gzip --db db_name /path/to/backup/bson/directory/
  

• 若备份确实是mongodump --gzip --archive=xxx.gz生成的归档文件，先执行chmod 644 filename.gz给文件加全局读权限——容器内mongorestore默认以mongodb用户运行，root权限创建的备份文件会因权限不足读不到内容，且不会直接抛权限报错。

3. 排查容器环境与数据库实例状态 #

• 容器内执行df -h检查磁盘剩余空间，剩余空间小于备份文件解压后大小（通常是压缩包的3-10倍）时，恢复进程会卡在IO等待无进度；执行top查看CPU、内存占用，内存耗尽触发cgroup OOM挂起时进程也不会返回报错。
• 不要通过交互式tty进入容器前台跑长耗时恢复任务，伪终端会话异常、超时断连都会导致进程挂起。直接在宿主机执行以下命令恢复，不需要进入容器：

  docker exec -i 你的mongodb容器名 mongorestore --gzip --archive --db db_name < /宿主机上备份文件的绝对路径/filename.gz
  

• 用mongosh连入MongoDB实例执行db.currentOp()查看锁状态：如果目标库存在残留集合锁、实例上有其他长任务占用全局写锁，恢复进程会持续等待锁释放，不会输出进度日志。这种情况可以先停掉实例上的其他业务写入，或者直接drop掉目标残留库后重新执行恢复。

4. 开启verbose日志定位具体卡点 #

• 给恢复命令加多级verbose参数打印详细执行日志，定位具体卡住的阶段：

  mongorestore -vvv --gzip --archive=filename.gz --db db_name
  

  • 日志停在归档元数据解析阶段：归档文件格式不匹配或已损坏
  • 日志停在索引构建阶段：大集合索引构建占满内存/IO卡住，可加--noIndexRestore参数先恢复数据，后续手动重建索引
  • 日志停在副本集写入确认阶段：副本集从节点同步延迟过高，可加--writeConcern {w:1}参数降低写入确认要求，待恢复完成后再等待副本同步

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