《挖出一个 627G 的"遗留数据库"》

今天处理机器发现一块遗留SSD。。上面有个目录：一个 3MB 的二进制文件、两个配置文件，加一个数据目录。是一个 SSDB，一个基于 LevelDB、兼容 Redis 协议的开源 KV 数据库。今晚花了一个多小时把它跑了起来，过程比想象中曲折：

老二进制在新系统上直接报 GLIBCXX 版本错误，只好从源码重新编译。

配置里绑定的是一台早已不存在的机器的 IP，改掉。

一启动，1 核 1G 的机器直接被 OOM 干掉。一看数据目录：627G，10.8 万个 sst 文件，光加载文件元信息就要好几个 G 内存。只好把云盘卸下来，挂到一台 8 核 32G 的新机器上。

终于启动成功，可所有查询命令都返回空。原来当年的人改过 SSDB 源码，自定义了数据类型，标准命令根本看不到这些数据。

用 Python 直接遍历 LevelDB，结果卡死了。原因是库的开头堆着上亿条"删除标记"，迭代器要一条条跳过。

最后干脆绕过数据库，自己写了个 C++ 小工具，逐个解析 sst 文件的二进制格式，把 key 和 value 的每个字段都逆向出来：数据从 2020 年一直记到今年。那上亿条被删除的数据，其实是 SSDB 自己的同步日志在自动滚动清理，真正的业务数据一条都没丢。

再利用"sst 文件写完就不再修改"的特性，只挑出 4 月以后生成的 1940 个文件来读，8 线程几分钟就导出了 2830 万条明细，压缩后 397M。

3点体会：

1）LevelDB 的删除只是打个标记，数据其实还在，被删的东西有时能找回来；
2）绕过上层系统、直接读底层存储格式，往往是最快的路；
3）还是AI牛逼，一路都是拷贝粘贴，提需求。。