近日有 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数据,我实验了一下,的确可行,而且原文的步骤介绍已经非常详细,这里就不再赘述。需要注意的是
- MongoDB 3.2 最新版本已经是了 wiredtiger 2.8,所以编译 wt 工具时,可以下载 2.8 版本的 wiredtiger 源代码。
- MongoDB 默认会对集合数据进行 snappy 压缩,所以一定要确保 snappy 正确安装,在执行 wt 工具时,通过扩展的形式加载 snappy lib,否则运行时会报错。
- 如果需要恢复的集合很多,本文的方法效率是很低的。
第五招:从文件里提取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云服务。
评论前必须登录!
注册