MongoDB无法启动,如何恢复数据?

近日有 MongoDB 用户遇到一个问题,使用 Wiredtiger 存储引擎的 MongoDB 无法启动,咨询我数据能否恢复回来,能恢复多少是多少 …

问题出现的场景据用户描述是「mongod磁盘写满了,导致进程 crash」,尝试重新启动,结果 wiredtiger 报错,错误信息类似如下,类似的问题 mongodb jira 上也有人提过,可以参考 SERVER-26924,说明此时 MongoDB 数据文件已经损坏。

2017-03-28T22:06:05.315-0500 W -        [initandlisten] Detected unclean shutdown - /data/mongodb/mongod.lock is not empty.
2017-03-28T22:06:05.315-0500 W STORAGE  [initandlisten] Recovering data from the last clean checkpoint.
2017-03-28T22:06:05.324-0500 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=13G,session_max=20000,eviction=(threads_max=4),statistics=(fast),log=(enabled=true,archive=true
,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2017-03-28T22:06:05.725-0500 E STORAGE  [initandlisten] WiredTiger (0) [1454119565:724960][1745:0x7f2ac9534bc0], file:WiredTiger.wt, cursor.next: read checksum error for 4096B block at offset 6
799360: block header checksum of 1769173605 doesn't match expected checksum of 4176084783
2017-03-28T22:06:05.725-0500 E STORAGE  [initandlisten] WiredTiger (0) [1454119565:725067][1745:0x7f2ac9534bc0], file:WiredTiger.wt, cursor.next: WiredTiger.wt: encountered an illegal file form
at or internal value
2017-03-28T22:06:05.725-0500 E STORAGE  [initandlisten] WiredTiger (-31804) [1454119565:725088][1745:0x7f2ac9534bc0], file:WiredTiger.wt, cursor.next: the process must exit and restart: WT_PANI
C: WiredTiger library panic
2017-03-28T22:06:05.725-0500 I -        [initandlisten] Fatal Assertion 28558

MongoDB 3.2及以后的版本已经很少会出现这样的问题,至少从我接触 MongoDB 到现在还没实际遇到过这个问题,不过既然问题已经发生,我们来看看遇到这种情况应该怎么恢复数据?

如何恢复 MongoDB 数据?

第一招: 从复制集其他节点同步数据

MongoDB 通过复制集能保证高可靠的数据存储,通常生产环境建议使用「3节点复制集」,这样即使其中一个节点崩溃了无法启动,我们可以直接将其数据清掉,重新启动后,以全新的 Secondary 节点加入复制集,它会自动的同步数据,这样也就达到了恢复数据的目的。

然而不幸的是,该用户的 MongoDB 实例 只部署了一个节点 … 我只能呵呵了 …

第二招:从最近的一个备份集恢复数据

有的时候可能出现一些极端的case,比如遇到自然灾害,复制集所有节点都挂了(或者像上面的用户这样,你的复制集只部署一个节点…),这时第一招就没法用了。

此时,如果靠谱的你刚好对数据做了备份,此时就排上用场了,比如你每天对 MongoDB 做一次全量备份,那么你就可以把数据恢复到最近一天的数据了;如果你更靠谱的还对数据做了增量本分,能恢复的数据就更多了。

但是可想而知,这个用户既然能部署一个「只有单个节点的复制集」,肯定也不会想到去对数据库进行备份了 …

第三招: repair 模式启动 MongoDB

当 MongoDB 无法启动时,通常是因为数据文件出现了不一致,mongod 支持以 repair 的模式启动,mongod 会尽可能的尝试自己去修复数据的不一致状态,修复过程中尽可能多的保留有效的数据。

但 repair 也不是对所有的场景都有效,repair 会先加载 MongoDB 所有的集合信息,然后针对每个集合来 repair,如果存储元数据的数据文件损坏,repair 也是没法工作的。

 mongod --repair // 用户尝试按这种方式启动,仍然报相同的错误

第四招:使用 wireditger 工具恢复

以上3招都不行,我的第一想法就是通过 wiredtiger 的 salvage 功能去尽可能的恢复数据(salvage 可翻译为数据打捞,即针对一个wt的数据文件,尽可能多的从中提取有效的数据),本来是想写个工具来做这个事情。不过调研了一下发现

 1. repair 模式启动,实现时也是调用的 wiredtiger 的 salvage 接口实现。
 2. wireditger 自带的一个命令行工具 wt,包含了 salvage 的功能。
 3. 找到一篇使用 wt 工具恢复 MongoDB 数据的文章,写的非常赞。

网友总结的使用 wiredtiger 工具 wt 恢复数据的方法原理很简单,就是通过恢复 wiredtiger 数据文件来恢复MongoDB数据,我实验了一下,的确可行,而且原文的步骤介绍已经非常详细,这里就不再赘述。需要注意的是

  1. MongoDB 3.2 最新版本已经是了 wiredtiger 2.8,所以编译 wt 工具时,可以下载 2.8 版本的 wiredtiger 源代码。
  2. MongoDB 默认会对集合数据进行 snappy 压缩,所以一定要确保 snappy 正确安装,在执行 wt 工具时,通过扩展的形式加载 snappy lib,否则运行时会报错。
  3. 如果需要恢复的集合很多,本文的方法效率是很低的。

第五招:从文件里提取bson文档来恢复

MongoDB json格式的文档,最终是以 BSON (Binary json) 格式持久化存储。

假设我们有个工具叫 bsonextract(有兴趣的同学可以尝试实现下贡献到社区里,直接调 BSON 的接口,实现起来不难),它能从一个数据文件里分析并提取出所有 BSON 格式的内容,那么我们也就达到了恢复数据的目的。

分析时,一段数据满足2个条件,我们即可认为是一个合法的 MongoDB 文档

  • 这段数据是一个合法的 BSON 文档
  • 包含一个 id 字段 (oplog 集合不包含 id 字段,但通常也没有去恢复 oplog 的必要)

上面这个方法不仅只能恢复 wiredtiger 的数据,对 MongoDB 所有存储引擎都有效。

总结

最后,issue SERVER-19815 里介绍了 MongoDB 一直在优化 MongoDB ,让它能在 repair 模式里自动处理各种数据文件损坏(或部分丢失)的场景,目标就是万一遇到数据集损坏的场景,repair都能自动修复掉。

下面是 repair 以后能自动处理的一些场景及处理方法

  • Database files missing

    • An entry for a file will exist in the catalogue, but on disk file is gone
    • Will be impossible to recover from, remove the entry from the catalogue
    • Warn the user strongly about this (Error message)
  • Database files corrupted

    • An entry for a file will exist in the catalogue, but on disk file is unable to be opened
    • Attempt to rename the collection with WiredTiger to a new table that has some mention of it being corrupted in the name
    • Re-create the same collection with the same name (in order to continue repair)
    • Warn the user strongly about this problem, the creation of the new collection
  • Index files missing
    • An entry will exist in the catalogue, but on disk file is gone
    • Build the index as part of repair
  • Index files corrupted
    • An entry will exist in the catalogue, but on disk file is unable to be opened
    • Drop, then rebuild the index as part of repair
  • MongoDB catalogue metadata may be out of alignment with the WT files on disk
    • When something is missing on disk, then this should be resolved by the changes above
    • When something is missing from the catalogue metadata but exists as a wt table on disk we have no recourse. We would need a user accessible function to import
    • If the WiredTiger metadata is corrupt, then the database is corrupt

作者简介

张友东,阿里云技术专家,主要关注分布式存储、NoSQL数据库等技术领域,先后参与TFS(淘宝分布式文件系统)Redis云数据库等项目,目前主要从事MongoDB云数据库的研发工作,致力于让开发者用上最好的MongoDB云服务。

发表评论