这是一个创建于 4710 天前的主题，其中的信息可能已经有所发展或是发生改变。
其中一个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
求相关经验的人士指点
第 1 条附言 · 2013 年 7 月 24 日
数据已经修复。 leveldb没坑我，是自己把自己坑了 :(
数据都是snappy压缩的，那个redis-storage我为了部署方便是直接把leveldb和snappy静态编译好然后从其他机器copy过来的。
而当时为了修复数据，直接在数据库所在机器安装了leveldb。但是坑爹的是没有连接上snappy库，我记得确实选择了SNPPY的。
后来发现在freebsd ports里面反复安装leveldb，虽然有SNAPPY选项，但是确实没法链snappy进来，于是手动修改了一些编译配置，终于把snappy编译进来了。
重新用那段python脚本，修复后基本上数据都在。
 |
1 lookhi 2013 年 7 月 22 日真悲惨，操作前你备份了吗？ |
 |
2 pubby 2013 年 7 月 22 日无备份 -_- 其它几个库有异地备份，这个库不是重要数据就没备份，但是重新生成这些数据的话也需要好几天时间，所以如果能修复就最好 大致看了一下.sst中的数据都在的。能修复大部分数据也行 |
 |
6 soli 2013 年 7 月 23 日LevelDB 的这个坑好大啊。 |
 |
12 clowwindy 2013 年 7 月 23 日 |
|
13 pubby 2013 年 7 月 23 日@clowwindy 那机器上跑了十几个leveldb库，就这个出问题了，看来还是存在一定的损坏概率。 另外就是数据恢复工具缺乏，那RepairDB()也太简陋了 |
|
16 pubby 2013 年 7 月 23 日leveldbutil dump *.sst 看来是没戏了 |
|
17 pubby 2013 年 7 月 24 日 1
@lookhi 数据都是snappy压缩的，那个redis-storage我为了部署方便是直接把leveldb和snappy静态编译好然后从其他机器copy过来的。 而当时为了修复数据，直接在数据库所在机器安装了leveldb。但是坑爹的是没有连接上snappy库，我记得确实选择了SNPPY的。 重新用那段python脚本，修复后基本上数据都在。 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。