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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 4468 天前的主题，其中的信息可能已经有所发展或是发生改变。

其中一个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 contens
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-07-24 16:01:29 +08:00

数据已经修复。 leveldb没坑我，是自己把自己坑了 :(

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

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

重新用那段python脚本，修复后基本上数据都在。

LevelDB

sst

db1

19 条回复 1970-01-01 08:00:00 +08:00

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

@lookhi

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

推荐SSDB
https://github.com/ideawu/ssdb

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。