mongorestore恢复无限挂起问题排查求助

这种卡在写关注（write concern）的情况我之前在Docker单实例环境里碰到过好几次，结合你的场景，咱们一步步来排查：

1. 先检查Docker容器的资源限制 #

MongoDB恢复过程需要内存来解压和处理数据，尤其是你的原库有89MB，解压后的数据量不算小。本地Docker默认给容器分配的内存可能不足（比如默认只有512MB），导致mongorestore进程被卡住：

• 用docker stats查看Mongo容器的实时内存使用情况，恢复时如果内存占满到100%，那大概率是内存不够。
• 调整Docker容器的内存限制，比如启动时加上--memory=1g --memory-swap=2g参数，给Mongo分配足够的内存。

2. 验证归档文件的完整性 #

生产环境导出的gzip归档可能在传输过程中损坏，导致恢复到一半卡住：

• 用gzip -t ./my-db.gz检查归档文件的完整性，如果报错说明文件损坏，重新从生产集群导出。
• 尝试手动解压归档：gzip -d ./my-db.gz，解压后用mongorestore直接恢复解压后的文件，看是否还会卡住。

3. 强制指定兼容的写关注参数 #

你的日志停在using write concern: w='1', j=false, fsync=false, wtimeout=0，可能是生产集群的写关注设置和本地单实例不匹配。本地单实例不需要等待副本确认，试试强制指定写关注为无确认模式：

mongorestore --gzip --archive ./my-db.gz --drop -u admin --authenticationDatabase admin --writeConcern "{w:0}" --verbose=5

w:0表示不需要Mongo返回写确认，能绕过因写关注等待导致的挂起。

4. 检查MongoDB版本兼容性 #

生产集群和本地Docker的MongoDB版本差异过大，可能会导致归档格式不兼容：

• 本地执行mongod --version，对比生产集群的版本。如果生产是5.x+，本地是3.x，大概率会有兼容性问题。尽量保持大版本一致（比如生产5.x，本地用5.x的Docker镜像）。

5. 查看MongoDB服务端日志 #

mongorestore客户端没输出错误，但Mongo服务端可能有日志记录问题：

• 用docker logs <你的Mongo容器名称>查看服务端日志，重点找有没有权限错误、磁盘空间不足、数据目录权限异常的信息。
• 同时检查本地磁盘空间，确保有足够的空间存放恢复后的89MB数据。

6. 简化恢复命令，排查单个集合问题 #

如果整体恢复卡住，试试只恢复一个小集合，看是否能成功：

mongorestore --gzip --archive ./my-db.gz --nsInclude "your-db-name.your-small-collection" -u admin --authenticationDatabase admin --verbose=5

如果单个集合能恢复，说明可能是某个大集合有数据异常，或者整体恢复时资源不足。

7. 检查Docker数据目录的挂载权限 #

如果Mongo的数据目录是挂载到本地主机的，可能存在权限问题，导致mongod进程无法写入数据：

• 进入容器执行docker exec -it <容器名称> ls -l /data/db，查看目录的所有者是否为mongod用户（UID通常是999）。
• 如果是本地目录挂载，调整本地目录权限：chown -R 999:999 /path/to/your/local/data-dir，确保容器内的mongod用户有写权限。

内容的提问来源于stack exchange，提问作者Helge Talvik Söderström