MongoDB 数据恢复：症状、原因、方法与难点

MongoDB 是国内互联网公司和新一代政企系统的标配文档库。它自带 journal 和副本集，"天然高可用"——但真到单机文件损坏、oplog 过期、整集群翻车的时候，恢复难度不比关系库低。

MongoDB 损坏的常见症状

启动类：mongod 起不来，报 WiredTiger 校验和错误（checksum failed）、"bad offset"、WiredTiger.wt / WiredTiger.turtle 元文件损坏，或报 unclean shutdown 后修复卡住。数据类：集合查询报错、文档莫名缺失、查询到一半 mongod 崩溃、mongodump 导出中途报错。副本集类：从节点同步永远追不上（oplog 窗口过期，报 too stale）、主从数据不一致。片集群类：balancer 卡死、chunk 迁移中断、config 库元数据与实际分片对不上。空间类：磁盘写满导致 journal 与数据文件双双半截。

MongoDB 损坏的常见原因

断电与 kill -9：WiredTiger 有 journal 护体，正常情况下 unclean shutdown 能自愈——但 journal 和数据写在同一个盘上时，盘出问题就是双杀。磁盘与文件系统损坏：bit rot、坏块、云盘抖动。磁盘写满：journal 和数据同时截断。人为：rm -rf dbpath、dropDatabase、误删集合、误操作 replSetReconfig、跨版本回退踩 FCV（featureCompatibilityVersion）限制。硬件与虚拟化层：超融合/云主机底层存储故障，上层看到的就是 MongoDB 文件损坏。

MongoDB 的恢复方法

让引擎自愈：有 journal 且只是元数据不一致的，正常启动会自动 replay，先让它跑完。从备份还原：mongodump/mongorestore、文件系统快照、Ops Manager/备份代理——这是最干净的路线。oplog 回放（PITR）：从最近备份点+oplog 日志重放到故障前某一秒，MongoDB 的时间点恢复就靠它。repair 模式：mongod --repair 重建数据文件——注意它会丢弃无法校验的文档，属于"保活不保全"，执行前必须镜像。集合级打捞：用 WiredTiger 的 salvage 能力或自研脚本扫数据文件，把还能读的文档抽出来重建集合。副本集救场：oplog 过期的从节点直接全量重同步；主从数据不一致时以多数派为准做一致性校验。片集群恢复：先修 config 库元数据，再逐片核对 chunk，最后跑一致性校验。

MongoDB 恢复的难点

oplog 窗口太短：oplog 是固定集合，容量撑得住的时间有限——发现事故时备份点往往已滑出窗口，PITR 无从谈起，备份频率决定一切。repair 的取舍：它是破坏性重建，能救库会丢文档，决策需要精确评估坏文档占比。文档级碎片：WiredTiger 数据文件里文档是变长的，抽页重组比关系库的行结构更费劲。片集群一致性：config 库、分片、chunk 三者交叉验证，恢复顺序错一步数据就对不上。生态年轻：关系库有 DUL、PC-3000 这类成熟军械，MongoDB 的底层打捞工具链要自己攒。

补天时代在 MongoDB 恢复上的优势

自研了 WiredTiger 数据文件的文档抽取与重组工具，不走 repair 的"丢文档换启动"路线，而是按集合定向打捞；副本集与片集群的恢复案例库覆盖互联网公司常见事故场景；评估时直接给三档方案——自愈/备份还原/底层打捞，各档成功率和工期明码，由客户按业务停损拍板。