k8s中mongo容器数据迁移之内存小坑

  近日在进行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集群中。
  操作：将数据从源环境迁移到目标环境。

操作过程及遇见问题

1. 使用mongodump -o XXX导出数据，未发现异常；
2. 使用mongorestore XXX时，运行到80%左右，程序直接退出，且会使pod自动重启，提示：

Failed: XXXX: error restoring from XXX/XXX/xxx.bson: insertion error: EOF
command terminated with exit code 137

排查过程：

1. 网上搜上面异常，大多都是说mongo v3.0.7有这个缺陷，可是我们当前版本比它高，应无此bug。
2. 排除mongo版本不一致：再去测试环境重新导入导出一次，难道是mongo不支持在线的导入和导出？在测试环境试后，测试环境可以正常导入导出，mongo版本也是一样的，因此跟版本应无关。
3. 排除数据异常：网上查了下，mongodump是在线备份的，那么使用--gzip参数，将导出文件压缩下，然后再恢复，发现还是一样的错误，说明数据在导出、传输时没有问题。在不同小版本间mongodump和mongorestore工具的文件大小有大差异，未深入研究其原因。
4. 排除空间不足：检查新环境文件系统，发现文件系统是完全足够的。
5. 逐个数据库导出/导入，诊断问题出原因：上面报错之前显示了导入的具体库名及集合名，那这次单独导入就拿它试验；
   导出命令：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%左右报最开始的错误。
6. 排除连接数问题：无意中搜到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+以上。时间有限，未做进一步的测试验证。