机器意外掉电后,leveldb数据几乎全部丢失,求如何修复

2013-07-22 19:31:25 +08:00
 pubby
其中一个5G左右的库,读写比较频繁。

供电跳闸,机器重启后该库里面所有的key都无法访问

找了段python代码,
#!/usr/local/bin/python

import leveldb
leveldb.RepairDB('/data/leveldb-db1')
修复数据库


修复过程中LOG里面全是这种信息:
2013/07/22-01:16:48.812110 801407400 Table #8527104: 0 entries Corruption: corrupted compressed block contents
2013/07/22-01:16:48.812123 801407400 Table #8527104: ignoring Corruption: corrupted compressed block contents
2013/07/22-01:16:48.812170 801407400 Archiving /data/sleveldb-db1/8527104.sst: OK


修复后只剩2个.sst文件,其他3千多个.sst文件都移动到了一个lost 目录

用 /data/leveldb-db1/lost 打开数据库,也无法读到任何key


求相关经验的人士指点
20085 次点击
所在节点   NoSQL
19 条回复
lookhi
2013-07-22 19:35:15 +08:00
真悲惨,操作前你备份了吗?
pubby
2013-07-22 19:39:31 +08:00
无备份 -_-

其它几个库有异地备份,这个库不是重要数据就没备份,但是重新生成这些数据的话也需要好几天时间,所以如果能修复就最好

大致看了一下.sst中的数据都在的。能修复大部分数据也行
pubby
2013-07-22 19:39:41 +08:00
Chewbacca
2013-07-23 08:41:25 +08:00
遇到过,那个修复的确不好用,修复后还是所有数据都丢了,好在当时用的 https://github.com/KDr2/redis-leveldb 这个,能分成好多个 DB,按时间分每月一个库,只丢了当月数据。
lookhi
2013-07-23 09:49:16 +08:00
@pubby 找现成程序估计不行了。
嗯,去找找看leveldb的数据格式,读出里面的数据来吧。
soli
2013-07-23 10:43:01 +08:00
LevelDB 的这个坑好大啊。
我们也在这上面吃过亏。
pubby
2013-07-23 11:01:19 +08:00
@Chewbacca
@lookhi
@soli
我以为只是最近写入的数据可能会丢失,没想到会这么严重


@soli 后来怎么避免的?除了备份措施之外。
soli
2013-07-23 11:18:40 +08:00
@pubby 换了别的数据库
clowwindy
2013-07-23 11:36:34 +08:00
@soli 改用了哪个数据库?
soli
2013-07-23 11:39:22 +08:00
@clowwindy SQLite 和 MongoDB

话说,MongoDB 用不好也坑
pubby
2013-07-23 13:34:43 +08:00
@soli
@clowwindy
我用的是redis-storage 用了redis接口加leveldb后端

https://github.com/rchunping/redis-storage

我又加了一些实用命令进去
clowwindy
2013-07-23 13:58:34 +08:00
@soli
@pubby

我们是在 iOS 的 App 上当存储的 backend 用,SQLite 太重。
因为 levelDB 也是 Chrome 和 Riak 的 backend,照理说应该不会有大坑的。
pubby
2013-07-23 14:23:06 +08:00
@clowwindy 那机器上跑了十几个leveldb库,就这个出问题了,看来还是存在一定的损坏概率。

另外就是数据恢复工具缺乏,那RepairDB()也太简陋了
LazyZhu
2013-07-23 15:34:58 +08:00
pubby
2013-07-23 15:59:06 +08:00
@LazyZhu thanks ,新项目可以尝试
pubby
2013-07-23 18:15:14 +08:00
leveldbutil dump *.sst
全是
Corruption: corrupted compressed block contents

看来是没戏了
pubby
2013-07-24 16:01:00 +08:00
@lookhi
@Chewbacca
@soli
@clowwindy
@LazyZhu
感谢,数据已经修复。 leveldb没坑我,是自己把自己坑了 :(

数据都是snappy压缩的,那个redis-storage我为了部署方便是直接把leveldb和snappy静态编译好然后从其他机器copy过来的。


而当时为了修复数据,直接在数据库所在机器安装了leveldb。但是坑爹的是没有连接上snappy库,我记得确实选择了SNPPY的。
后来发现在freebsd ports里面反复安装leveldb,虽然有SNAPPY选项,但是确实没法链snappy进来,于是手动修改了一些编译配置,终于把snappy编译进来了。



重新用那段python脚本,修复后基本上数据都在。
soli
2013-07-24 16:10:18 +08:00
@pubby 想请教一下,你 LevelDB 的热备是怎么做的。记得当初我们用 LevelDB 的时候是没法热备的。
pubby
2013-07-24 16:40:59 +08:00
@soli 不是严格意义上的热备
我这边应用比较特殊,数据都是只读即可

本地有专门生成数据的机器,把数据存入本地leveldb,同时程序会把写入的数据加入一个同步队列,然后另外一个同步程序定时把队列里的数据同步到几台服务器上并写入服务器上的leveldb。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/76618

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX