首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  NoSQL

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

  •  
  •   pubby · 2013-07-22 19:31:25 +08:00 · 12321 次点击
    这是一个创建于 2329 天前的主题,其中的信息可能已经有所发展或是发生改变。
    其中一个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-07-24 16:01:29 +08:00
    数据已经修复。 leveldb没坑我,是自己把自己坑了 :(

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


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



    重新用那段python脚本,修复后基本上数据都在。
    19 回复  |  直到 1970-01-01 08:00:00 +08:00
        1
    lookhi   2013-07-22 19:35:15 +08:00
    真悲惨,操作前你备份了吗?
        2
    pubby   2013-07-22 19:39:31 +08:00
    无备份 -_-

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

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


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

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

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

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

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

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

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

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


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



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

    本地有专门生成数据的机器,把数据存入本地leveldb,同时程序会把写入的数据加入一个同步队列,然后另外一个同步程序定时把队列里的数据同步到几台服务器上并写入服务器上的leveldb。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2267 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 26ms · UTC 10:41 · PVG 18:41 · LAX 02:41 · JFK 05:41
    ♥ Do have faith in what you're doing.