干这行最怕半夜手机响，响起来八成是数据库挂了。MongoDB平时看着挺皮实，可真遇上服务器断电、磁盘写满或者副本集脑裂，那手忙脚乱的样子我见太多了。今天不聊那些晦涩的官方文档，就说说我这些年踩过的坑，把MongoDB崩溃后怎么把数据捞回来的完整路子捋一遍。记住一个核心原则：先保数据文件，再谈恢复，顺序错了神仙都救不了你。
第一步永远是止损，不是急着重启。很多人一看服务挂了就systemctl restart mongod，这是找死。崩溃后的数据文件可能处于不一致状态，WiredTiger引擎的checkpoint没落盘，直接重启轻则丢最近几秒的数据，重则把整个数据目录搞坏。正确做法是先看日志，/var/log/mongodb/mongod.log里几百行会告诉你崩溃原因。是磁盘满了，还是OOM killer把进程杀了，还是主从同步断链？原因不同，恢复策略完全不一样。先把数据目录整个拷贝一份到安全位置，用cp -a保留权限和时间戳，这是你的后悔药。
如果日志显示是“Fatal Assertion”或者“WiredTiger error”，大概率是数据文件损坏了。这时候别慌，mongod有个--repair参数，但用法有讲究。小数据量可以直接mongod --dbpath /var/lib/mongodb --repair，它会重建索引和修复损坏的记录。但超过几十GB的库，这个操作跑起来要人老命，而且修复过程中不能中断。我的经验是，先单独把损坏的collection文件拎出来，用mongodump指定db和collection导出，能导出多少是多少。实在导不出来的，再用--repair，但要有心理准备，修复完的库可能丢数据，索引也要重建。
副本集环境下恢复思路要改一改。如果整个副本集都挂了，重启顺序是：先找数据最新、oplog时间戳最靠后的那个节点，单独以单机模式（--replSet参数去掉）启动它，让它先把数据稳定下来。然后其他节点再依次启动，通过rs.reconfig()把副本集拉回来。这里有个坑：如果主节点数据损坏，而从节点数据是好的，千万别用主节点的旧数据去覆盖从节点，要反过来。我以前就干过这蠢事，拿着损坏的primary数据去同步，结果把健康的secondary也搞坏了。
备份文件恢复是最常规的操作，但里面细节多。用mongodump做的逻辑备份，恢复就用mongorestore，注意--drop参数会先删掉目标库的同名collection，慎用。用文件系统快照或者云盘快照做的物理备份，恢复起来更直接，把数据目录整个替换回去就行。但物理备份和当前数据版本不匹配是大忌，比如备份是4.0的，线上已经升到5.0，直接替换数据目录会让mongod拒绝启动。这时候得用--setParameter downgrade之类的招，或者老老实实逻辑恢复。
说到实战技巧，有个东西叫“稳定点”（last stable checkpoint）。WiredTiger引擎每隔60秒会生成一个checkpoint，记录当时所有数据的一致性快照。崩溃后重启，引擎会自动回滚到最近一次checkpoint，然后重放journal日志。所以journal文件千万别删，也别随意调小journal的commit间隔。如果崩溃后重启发现数据停留在某个时间点，别急着骂街，检查一下journal目录下有没有残留的*.j文件，有的话mongod启动时会自动重放。
还有一个容易被忽略的恢复场景：集合被误删。rm -rf删除了某个collection的物理文件，但mongod还在运行，这时候千万别重启进程，进程的内存里可能还有脏页没刷盘。正确做法是立即用collection.drop()删除残留的元数据，然后用最新的备份恢复该集合，再通过oplog重放恢复到误删时间点。如果连oplog都没了，那就只能接受现实，把损失降到最低。
说点掏心窝子的。MongoDB恢复这事，七分靠平时，三分靠临场。平时把备份策略做扎实，全量备份加oplog增量，每天验证一次恢复流程，别等真出事才发现备份文件是坏的。恢复过程中多留几个心眼，每次操作前都问自己一句“这步错了怎么回滚”。真到了数据全丢那一步，也别崩溃，拿着的备份文件去专业数据恢复公司，他们能对WiredTiger的底层文件做深度解析，但价格不菲，所以平时该花的钱别省。
写这篇东西的时候我又翻了翻自己的故障处理记录，发现百分之八十的崩溃原因都是监控不到位——磁盘容量没报警、慢查询没预警、副本集延迟没盯住。MongoDB恢复数据库不是玄学，是门手艺活，但最好的手艺是让数据库根本不崩。把自动巡检脚本跑起来，把告警阈值调合理，把备份验证纳入月度例行工作，比读十篇恢复教程都管用。真遇到了崩溃，按上面这套流程走，稳扎稳打，数据大概率能捞回来，顶多丢几秒到几分钟的增量数据，这在生产环境里完全能接受。
