MongoDB服务启动失败，修复时触发aborting after fassert() failure报错求助

我之前处理过好几次类似的情况，用shutdown -rF now这种强制冷重启服务器，很容易打断MongoDB的磁盘写入操作，直接导致数据文件损坏，这就是你碰到aborting after fassert() failure报错的根本原因。下面是一步步的排查修复方案：

第一步：先做数据备份（重中之重！） #

不管后续怎么操作，先把当前的数据目录完整备份，避免操作失误彻底丢数据：

sudo cp -r /var/lib/mongodb /var/lib/mongodb_backup_$(date +%Y%m%d_%H%M%S)

第二步：尝试用配置文件启动修复模式 #

单独用--repair参数有时候会忽略MongoDB配置里的一些关键设置（比如WiredTiger的缓存大小），试试用系统默认的配置文件来启动修复：

# 先确保没有残留的mongod进程
sudo pkill mongod
# 用配置文件启动修复
sudo mongod --config /etc/mongod.conf --repair

如果这次修复成功，直接跳到第四步启动服务就行。要是还是报错，说明数据损坏比较严重，继续往下走。

第三步：定位并处理损坏的具体文件 #

打开MongoDB的日志文件（默认路径是/var/log/mongodb/mongod.log），找fassert()报错附近的详细信息，通常会明确指出哪个WiredTiger数据文件损坏了，比如类似这样的日志：

WiredTiger error 22: Invalid argument: [1699999999:999999][1234:0x7fxxxxxxxxx], file: collection-xx-xxxxx.wt, WT_SESSION.open: read checksum error for 4096B block at offset 0: calculated block checksum of 0x12345678 doesn't match expected checksum of 0x87654321

找到这个损坏的文件后，先删除它（记得已经备份过了！），然后再尝试修复：

# 删除损坏的文件，替换成你日志里找到的文件名
sudo rm /var/lib/mongodb/collection-xx-xxxxx.wt
# 再次执行修复
sudo mongod --repair --dbpath /var/lib/mongodb

⚠️ 注意：删除损坏的文件会丢失对应集合的数据，这是迫不得已的操作，只有当文件完全无法修复时才用。

第四步：修复完成后启动并验证服务 #

修复成功后，启动MongoDB服务并检查状态：

sudo service mongod start
# 确认服务是否正常运行
sudo service mongod status

如果服务状态显示active (running)，登录MongoDB客户端验证数据完整性：

mongo
# 查看所有数据库
show dbs
# 切换到你的业务数据库，检查关键集合
use your_business_db
db.your_key_collection.find().count()

后续预防建议 #

• 绝对避免使用shutdown -rF now这类强制重启命令，正常重启服务器应该用shutdown -r now，给MongoDB足够的时间优雅关闭连接、刷写数据到磁盘。
• 配置定期自动备份：可以用mongodump做逻辑备份，或者用LVM快照做文件级备份，根据数据量选择合适的方式。
• 开启MongoDB的日志轮转，避免日志文件过大，方便后续排查问题。

内容的提问来源于stack exchange，提问作者m7majidi