近日在进行mongo的数据迁移，使用mongodump及mongorestore工具，遇到了导出正常导入失败，无报错日志，容器退出码是137，直接容器自行重启了。现简要说说是可能是什么原因。
环境信息
源环境：mongo v3.4.10，数据量磁盘存储是3-4GB，使用mongodump不加--gzip参数时有19GB，加--gzip参数后是2GB。以单pod形式运行在A网络区的k8s集群中。
目标环境：mongo v3.4.24，以单pod形式运行在B网络区的k8s集群中。
操作：将数据从源环境迁移到目标环境。
操作过程及遇见问题
- 使用mongodump -o XXX导出数据，未发现异常；
- 使用mongorestore XXX时，运行到80%左右，程序直接退出，且会使pod自动重启，提示：
Failed: XXXX: error restoring from XXX/XXX/xxx.bson: insertion error: EOF
command terminated with exit code 137
排查过程：
- 网上搜上面异常，大多都是说mongo v3.0.7有这个缺陷，可是我们当前版本比它高，应无此bug。
- 排除mongo版本不一致：再去测试环境重新导入导出一次，难道是mongo不支持在线的导入和导出？在测试环境试后，测试环境可以正常导入导出，mongo版本也是一样的，因此跟版本应无关。
- 排除数据异常：网上查了下，mongodump是在线备份的，那么使用--gzip参数，将导出文件压缩下，然后再恢复，发现还是一样的错误，说明数据在导出、传输时没有问题。在不同小版本间mongodump和mongorestore工具的文件大小有大差异，未深入研究其原因。
- 排除空间不足：检查新环境文件系统，发现文件系统是完全足够的。
- 逐个数据库导出/导入，诊断问题出原因：上面报错之前显示了导入的具体库名及集合名，那这次单独导入就拿它试验；
导出命令：mongodump --gzip -d xxx -o XXX/
异常导入命令：mongorestore -d xxx --stopOnError --drop XXX/
此时导入报错，说遇到XXX/xxx后不知道该怎么处理，于是就忽略XXX/xxx文件夹，程序就直接结束了。可是XXX/xxx刚好就是导入的库的路径啊。这又是何原因呢？
对于小白来说，遇到这种不知所云的报错，真是头疼，只有不断尝试，把XXX/修改成XXX/xxx，然后再跑，此时通了。
成功导入命令：mongorestore -d xxx --stopOnError --drop XXX/xxx
不过此时导入依然是导入到80%左右报最开始的错误。 - 排除连接数问题：无意中搜到MongoDump与MongoRestore若干小坑，于是检查链接ulimit，发现是不受限制，然后再尝试导入，同时观察
db.serverStatus().connections，发现也是足够的，离满还差得远。
问题原因
由上面检查连接数，延伸到是否其它资源不足导致pod退出呢？而pod的资源主要就是CPU和内存（文件系统已经检查过了）。
核查完pod的CPU、内存后，发现CPU的最高使用率没有接近或超过yaml里设定的limits，而内存实际使用有16GB，yaml里limits限定是18G，已经很接近了。那么是否可能是内存不够了？
重新扩大yaml的内存limits为25G，然后再重新导入，导入成功！
此时再检查该pos内存使用率，发现最高使用到23GB了。
总结归纳
本人不是专业搞mongo的，本次是初次使用，因此，可能本问题比较简单，但还是记录下来，以备后用。
初步猜测导入时的内存大小与导出时最大的单个bson文件大小有关。本次迁移中，单个bson文件最大是18G，而考虑到额外空间，内存至少得18G+以上。时间有限，未做进一步的测试验证。
网友评论