每周一坑-mongo每次启动后莫名关闭

发布时间 2023-04-19 22:16:33作者: windysai
每周一坑-mongo每次启动后莫名关闭
  今天这个问题搞了大半天。。。明天找开发确认下功能是否已恢复正常。
  无意中发现某项目用完阿里云整个2T的oss对象存储,大家都知道,用完额度,超过的部分就会从用户余额去扣费。按道理来说,买的2T针对项目程序上传来说是够的,也不太可能从这里清理数据,那就只能从该oss创建的备份bucket去清理。
  清理数据过程中,我知道mongo的备份数据是比较占空间的,所以尽量清掉该部分历史数据,能达到事半功倍的效果。然而,我发现有个mongo备份目录竟然是空的(备份脚本每天运行),我就试试手动运行下是否成功,是脚本问题,还是连接问题,记得以前是一直能用的,运行下来说连接不上,再看看mongo服务,压根没起。于是就运行mongo启动命令,一边看着mongo日志,如下图:
     注意:连接该mongo的是一个tomcat服务
  话说如果mongo挂掉那么久,这个tomcat服务所呈现的web服务应该会被很多人发现才对,然而这么久,却没有收到任何报障(后来开发说xx11月休产假前就有问题了(知而不上报好家伙,我可是各种方法用尽解决不了直接上报我领导),说是异步处理,所以页面看着还是很正常的,查数据可能就有问题)

FTDC     [ftdc] Unclean full-time diagnostic data capture shutdown detected, found interim file, some metrics may have been lost. OK
   我找了一轮问题解决方案,很多都说干掉 mongo配置文件data目录下的diagnostic目录数据,然后删掉 mongodb.lock,重启就能解决。
   多次尝试,都是开启后过一段时间,看到tomcat服务连接过来后,mongo就自动挂了。mongo日志看不出什么。
踩坑一:涉及重要数据的问题,不要太依赖ai,记得记得做好备份
   无果之后,我开始问我的小可爱:
在MongoDB xxx版本中,如果启动后很快自行关闭,可能有以下几种可能的原因:
配置文件错误:MongoDB的配置文件可能包含错误的配置项,导致启动后出现错误,从而导致自动关闭。您可以检查配置文件(通常为mongod.conf)并确保其中的配置项正确设置,包括端口号、数据目录、日志文件路径等。
系统资源不足:如果系统资源(如内存、磁盘空间)不足,MongoDB可能无法正常运行并在启动后自行关闭。请确保系统有足够的可用资源供MongoDB使用。
数据库损坏:如果MongoDB的数据文件损坏或不一致,可能导致启动后自行关闭。您可以通过运行mongod命令时指定--repair选项来尝试修复损坏的数据库文件。
端口冲突:如果MongoDB的端口号与其他进程或服务的端口号冲突,可能导致MongoDB无法正常启动并在启动后自行关闭。您可以尝试更改MongoDB的端口号,确保其不与其他进程或服务的端口号冲突。
日志中的错误:检查MongoDB的日志文件,通常位于配置文件中指定的日志文件路径,查看是否有任何错误或异常信息。这可以帮助您确定问题的根本原因。
如果您仍然无法解决问题,建议查阅MongoDB的官方文档或社区论坛,或联系MongoDB的技术支持团队以获取进一步的帮助。

   配置文件对一轮,没问题;端口冲突,木有的事;日志中的错误,看不出有问题突破点的地方。系统资源不足,tomcat和mongo的服务器资源负载都还好。

   我就相信它说的可能是数据损坏,叫我尝试修复数据库(运行:mongod --repair),病急乱投医,做最后的尝试。

即使您没有更改MongoDB的配置文件,仍然有可能出现启动后自行关闭的问题。以下是一些可能的解决方法:
检查日志文件:查看MongoDB的日志文件,通常位于配置文件中指定的日志文件路径,以查找任何错误或异常信息。这可以帮助您确定问题的根本原因。例如,可能会有与文件权限、文件路径、网络连接等相关的错误信息。
检查系统资源:确保系统有足够的可用资源供MongoDB使用,包括足够的内存、磁盘空间和文件描述符等。资源不足可能导致MongoDB启动后自行关闭。
检查端口冲突:确保MongoDB使用的端口号没有与其他进程或服务的端口号冲突。您可以尝试更改MongoDB的端口号,并确保在启动时指定了正确的端口号。
检查后台运行模式:如果您在启动MongoDB时使用了--fork参数将其作为后台进程运行,可以尝试在前台模式下启动MongoDB,以便查看控制台输出和错误信息,例如使用以下命令启动MongoDB:
mongod --config /path/to/mongod.conf
尝试修复数据库:如果MongoDB的数据文件损坏或不一致,可能会导致启动后自行关闭。您可以尝试运行mongod命令时指定--repair选项来尝试修复损坏的数据库文件,例如:
mongod --repair
检查安装完整性:确保MongoDB的安装完整且没有损坏的文件。您可以重新下载和安装MongoDB,并确保安装过程中没有发生错误。
如果您仍然无法解决问题,建议查阅MongoDB的官方文档或社区论坛,或联系MongoDB的技术支持团队以获取进一步的帮助。

   修复完再启动mongo报错:

[initandlisten] Fatal assertion 28579 UnsupportedFormat: Unable to find metadata for table

Fatal assertion 28579 UnsupportedFormat: Unable to find metadata for table:index-1--xxx Index:

   这下死翘翘了,肯定是这个命令有问题,它没给我说风险,我也没去查。贴出报错信息继续问它,说只能恢复备份(mongodumpmongorestore)或恢复操作日志或重建索引或用数据恢复工具。

  它也开始意识到问题严重性了,开始每段回复都加上这句:

在执行任何操作之前,请务必备份数据库文件,以防止数据丢失或进一步损坏。同时,建议定期进行数据库备份,并测试备份的可用性,以便在出现数据丢失或其他故障时能够快速恢复。

  我也意识到 --repair是有问题的,就问了它风险。

   也就是我刚刚的repair命令导致原来没有损坏的数据被损坏了,然后前面也说过,这个mongo备份不成功,没有数据可恢复。幸好我对这机器做了每周2次的快照备份,只能买个按量付费的ECS,把备份的快照创建镜像,恢复到该按量的ECS上,把mongo数据目录拷贝回去。。。终于又回到开始的这个报错,不是致命性数据损坏,谢天谢地。

[ftdc] Unclean full-time diagnostic data capture shutdown detected
 
踩坑二:系统资源不够?
   从日志来看,只要mongo一起来,tomcat就会有连接过来,随之而来,mongo服务挂掉,tomcat照常启动。
   尝试把tomcat关了,让这个tomcat程序连接断开。看看mongo服务是否能起来不挂,确实没问题。然后我开始开回tomcat,没一会mongo又挂了。我就反馈给领导:有空叫人处理下xxx,程序一起来,mongo就自动挂了。领导叫我确认下是不是资源不够导致的,磁盘、内存之类的。话说tomcat服务所在的资源确实不太够,系统负载经常都超过1。
  于是我试着把整个tomcat服务挪到一个相对空闲的服务器,跑起来,情况还是老样子。临下班领导问我问题是否已解决,我说还是不行,资源非常足够,tomcat报错信息如下:
  看下面报错信息,怀疑是程序的mongo驱动版本问题

   当领导跟开发确认过这个数据并不是很重要后,叫我重装,或者改mongo数据目录,改到一个空的位置,或者备份直接删掉数据目录,看是否正常。

  我采取直接修改mongo数据目录,mongo再也没出现tomcat一起来,就自动死掉的情况。

  那就是mongo的数据目录有点问题。至于程序功能是否正常,明天再问问开发