上周有个朋友半夜给我打电话，语气里带着哭腔——他们公司的MongoDB数据库突然崩了，所有用户数据看起来像是被清空了。这种场景我太熟悉了，干这行的谁没遇到过几次数据库“翻车”？MongoDB作为非关系型数据库的扛把子，用起来确实爽，但一旦出问题，数据恢复的难度往往比传统关系型数据库更让人头疼。今天我就把自己这些年踩过的坑、总结出的经验，掰开揉碎了聊聊MongoDB数据恢复的那些事儿。
先说最基础也是最容易忽略的一点：备份是数据恢复的底线。很多团队觉得MongoDB自带副本集，高可用性没问题，就忘了做定期备份。结果副本集里的成员同时出问题，或者误操作覆盖了数据，这时候才发现“高可用”不等于“数据不丢”。MongoDB官方推荐用和这对组合拳，用法简单到让人发指：，然后就能把数据原样导回去。但这里有个坑——默认的不会备份索引，如果你生产环境有几十个G的数据，重建索引能让你等得怀疑人生。所以务必加上参数，这样能保证备份点之后的数据一致性，恢复时也更快。
但备份再勤快，也架不住手滑。比如有人用删了整个集合，或者用把关键字段全清空了。这时候如果备份文件是三天前的，中间这三天的新增数据就全没了。别慌，MongoDB的WiredTiger存储引擎有个隐藏技能——它会在磁盘上保留数据文件的旧版本。你可以尝试用配合选项，从oplog日志里重放操作。具体步骤是：先停掉业务写入，用导出当前数据库，然后到另一个实例，再通过分析oplog.bson文件，找出误操作前后的时间点，用脚本过滤出需要恢复的数据。这活儿技术含量不低，但能救回大部分数据。
如果连oplog都被覆盖了，那就得祭出终极武器——WiredTiger的“脏页”恢复。MongoDB在写入数据时，会先写入journal日志，然后才更新内存中的脏页，最后才刷到磁盘的数据文件。所以如果你的数据库是突然断电或者进程被kill，journal文件里通常还存着没来得及落盘的数据。默认情况下，MongoDB启动时会自动回放journal，但万一journal也损坏了（比如磁盘坏道），你可以尝试用命令。这个命令会对所有数据文件进行全量扫描，重建缺失的文档和索引。但警告一句：极费时间，100G的数据可能需要跑十几个小时，而且过程中千万不能中断，否则数据文件会变得一塌糊涂。
不过，以上这些方法都建立在数据文件本身没被物理损坏的前提下。如果磁盘真的挂了，比如SSD主控芯片烧了，或者云厂商的硬盘彻底不可读，那你就得靠MongoDB Atlas这类托管服务的内置快照恢复了。但如果你是自己维护的物理机，建议提前配置LVM快照或者文件系统级别的快照（比如ZFS），这样即使数据文件损坏，也能在秒级回滚到之前的状态。我见过最夸张的一个案例，某团队用了RAID 0阵列，结果一块硬盘坏了，所有数据全完蛋，连都救不回来。所以硬件冗余和数据备份，这两件事千万别偷懒。
说到具体误操作场景，最恶心的是删库跑路型——比如有人执行了。这时候如果启用了副本集，并且oplog大小设置得足够大（建议至少24小时的写入量），你可以通过克隆一个从节点的方式来恢复。具体操作是：找一台新的服务器，用启动一个空实例，然后从主节点同步oplog。但要注意，同步过程中必须禁止主节点做任何写入，否则oplog会覆盖掉你要恢复的那个时间点。更稳妥的做法是，用导出主节点的oplog，然后通过重放到新实例，并指定参数限制时间窗口。这招我帮朋友恢复过三次，成功率大概70%，关键看oplog是否完整。
还有一个容易被忽视的恢复场景：升级版本导致的兼容性问题。比如从MongoDB 3.6直接跳到5.0，中间跨了多个大版本，数据文件格式不兼容，启动时会报错误。这时候千万别直接跑，因为新版MongoDB的会尝试用新格式重写数据文件，一旦失败，旧文件也会被破坏。正确做法是：先找到旧版本的二进制文件（比如3.6的mongod），用它来启动并导出数据，然后再用新版导入。这听起来麻烦，但能避免数据彻底丢失。我见过有人图省事直接升级，结果数据文件全变成垃圾文件，只能从一周前的磁带备份里恢复。
想说的是，数据恢复这件事，七分靠预案，三分靠运气。我见过太多团队，平时不测试备份，等出事了才发现备份文件是坏的。或者恢复了数据，但业务已经停摆6小时，损失早就超过了数据本身的价值。所以，给你的MongoDB数据库做三件事：第一，每周至少一次全量备份，每天一次增量备份，备份文件要异地存储；第二，每季度做一次恢复演练，把备份文件恢复到测试环境，验证数据完整性和业务逻辑；第三，设置oplog大小不低于24小时，并且开启慢查询日志，这样即使出问题也能快速定位时间点。数据库恢复从来不是“能不能修”的问题，而是“你敢不敢赌”的问题——赌运气的成本，往往比做备份高得多。
