MongoDB为我工作了好几个月，直到一两周前我意外关闭。从那以后，我一直在标题中遇到错误，使错误变成无效的参数，然后出现库恐慌，然后是导致MongoDB崩溃的致命断言。
现在，我已经完成了研究：正常的答案是运行修复功能，并确保SELinux不会破坏该过程。这些都不起作用。该错误在WiredTiger的检查点过程中引发，因此对数据库的读/写不是问题，并且由于它是在检查点过程中，因此可以保证MongoDB的停留时间不会超过一天。
要清楚：数据库中的所有文件均归mongod：mongod所有，其权限设置为600（默认设置，我尝试将它们设置为755，以查看是否已修复该问题，但事实并非如此）。我在CentOS 7机器上将mongodb作为服务运行，并且服务文件指定它应以mongod用户身份运行。 mongod.conf文件将已安装的文件系统指定为数据库，对此感到满意的是，直到意外关闭。我正在运行MongoDB 4.0.1版，因此如果我禁用日记功能，WiredTiger确实不喜欢它（忽略了我不应该首先禁用它的事实）。
我觉得我已经用尽了所有选项，而我唯一能做的就是备份数据并重新安装MongoDB。有什么我想念的吗？
答案 0 :(得分：0)
通过mongodump创建数据备份后，关闭mongo，使用rm -rf'path-to-database'删除整个数据库，重新启动mongo（不使用复制配置），并使用mongorestore，mongodb还原数据仍然崩溃。但是，这一次是在open：操作不允许后发生不变故障。我能想到的唯一结论是数据本身已经以某种方式损坏。幸运的是，可以说，这不是“关键任务”数据，我可以轻松获得新数据。
不幸的是，这没有回答我最初的问题“我还有什么其他选择？”。但是，我仍然发布此消息，以防其他人遇到此类问题。
编辑：不变的问题是由我忘记重新初始化复制集引起的。修复之后，它很干净。因此，我不再相信这是一个数据损坏问题，而是一个检查点损坏问题。
编辑2：因此，大约一个星期后，又出现了这个问题，在尝试了各种调试方法的又一周之后，我尝试将mongo进程简单地移到另一台服务器上。到目前为止，这一直在起作用。以前的服务器正在运行（我什至无法在某一时刻运行最高-另一个进程锁定了运行它所必需的库文件），所以这里希望当前的服务器不遵循套件。