每周一坑-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:
这下死翘翘了，肯定是这个命令有问题，它没给我说风险，我也没去查。贴出报错信息继续问它，说只能恢复备份（mongodump 和 mongorestore）或恢复操作日志或重建索引或用数据恢复工具。
它也开始意识到问题严重性了，开始每段回复都加上这句：
在执行任何操作之前，请务必备份数据库文件，以防止数据丢失或进一步损坏。同时，建议定期进行数据库备份，并测试备份的可用性，以便在出现数据丢失或其他故障时能够快速恢复。
我也意识到 --repair是有问题的，就问了它风险。
也就是我刚刚的repair命令导致原来没有损坏的数据被损坏了，然后前面也说过，这个mongo备份不成功，没有数据可恢复。幸好我对这机器做了每周2次的快照备份，只能买个按量付费的ECS，把备份的快照创建镜像，恢复到该按量的ECS上，把mongo数据目录拷贝回去。。。终于又回到开始的这个报错，不是致命性数据损坏，谢天谢地。
[ftdc] Unclean full-time diagnostic data capture shutdown detected话说这个ai，昨晚我测了下，关于excel表格数据分析，新建数据样例图表不错，分析数据叫它对整列进行大小判断（数值超过多少，就返回是，否则否），一直只给我一行判断结果的excel公式，而不是选中的整列数据，每行都返回一个结果。连问3,4次还是老样子，最后纳闷关掉它。。。不知道是我问得不对，还是不太聪明。。。 凡事要中立客观点，ai对钉钉聊天记录做会话总结还是很棒的，至于这个怎么做，老板没有告诉我。。。有空研究下。 踩坑二：系统资源不够？ 从日志来看，只要mongo一起来，tomcat就会有连接过来，随之而来，mongo服务挂掉，tomcat照常启动。 尝试把tomcat关了，让这个tomcat程序连接断开。看看mongo服务是否能起来不挂，确实没问题。然后我开始开回tomcat，没一会mongo又挂了。我就反馈给领导：有空叫人处理下xxx，程序一起来，mongo就自动挂了。领导叫我确认下是不是资源不够导致的，磁盘、内存之类的。话说tomcat服务所在的资源确实不太够，系统负载经常都超过1。 于是我试着把整个tomcat服务挪到一个相对空闲的服务器，跑起来，情况还是老样子。临下班领导问我问题是否已解决，我说还是不行，资源非常足够，tomcat报错信息如下： 看下面报错信息，怀疑是程序的mongo驱动版本问题
当领导跟开发确认过这个数据并不是很重要后，叫我重装，或者改mongo数据目录，改到一个空的位置，或者备份直接删掉数据目录，看是否正常。
我采取直接修改mongo数据目录，mongo再也没出现tomcat一起来，就自动死掉的情况。
那就是mongo的数据目录有点问题。至于程序功能是否正常，明天再问问开发
标签：mongo,tomcat,MongoDB,备份,莫名,一坑,日志,端口号 From： https://www.cnblogs.com/windysai/p/17334685.html