1、起因,一个flushdb命令
因为误操作,
输入了一个flushdb命令,
导到redis里0号库里的数据全部清空,OMG,这里有不少重要信息,如果被领导知道,必开除
2、appendonly留有生机
仔细想想,当时数据备份是有设置日志备份的,找到Redis的配置文件redis.conf
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
于是将appendonly.aof文件导出,自己在线下又搭了个redis,开始尝试将数据恢复出来
3、编辑日志文件
我最开始用的EditPlus,拉开文件,拉到最底下,看到了flushdb的操作记录,呵呵,心情大好
但是无论你怎么改appendonly.aof,都无法通过redis-check-aof的检验,会一直报数据有错,使用fix方法反而会将所有记录清空,反正是不能用EditPlus这种普通的文本编辑器了,
要用个十六进制进制编辑器,于是download了一个Hex Editor。
多找几个aof文件用来进行对比,分析它的数据格式(这个需要点耐心,反正我是用猜的),分析得出其flushdb在其中对应的字符是"*1..$7..flushdb..",删除这一段后保存。
将保存好的appendonly.aof上传到Redis的服务器,重启Redis,顺利启动,
用redis-cli查看数据,输入
keys *
有数据了,长吁一口气
这事太丢人了,要引以为戒,想办法抹掉能抹的痕迹。事了拂衣去,早早洗了睡,不想再掺和运维的事了,太吓人了。