共计 947 个字符，预计需要花费 3 分钟才能阅读完成。
前言
前段时间这个新闻在行业内闹的满城风雨
一名程序员因为对公司不满，删除了公司的数据库，起初被判 7 年，这也给咱们程序员敲响了一记警钟，无论产生什么，这种做法都是十分不得当的，不光是职业道德的问题，而且还会收到法律的制裁。然而咱们都晓得 redis 中有一个叫 flushall 的命令，如果不小心在线上执行了会怎么办呢？
tips: 本文仅仅作为实践解说，如果要尝试请在本地环境尝试，若在线上执行之后导致数据无奈复原，后果自负！！！
复原数据思路
- 大家都晓得 redis 和 memcache 都作为缓存应用，redis 有一点最大的不同在于数据能够长久化，redis 的长久化是基于 aof 和 rdb 日志来进行长久化的，所以在复原数据的时候咱们能够思考用 日志 来复原
- rdb 日志都是二进制文件，也是不可读的，在这方面可能做不了太多事件，然而 aof 文件都是可读性很好的文件，而且外面记录了每一条命令(当然也记录了那一条 flushall 命令)，所以咱们能够用 aof 日志来复原整个 redis 数据
- 然而大家留神 aof 日志是有重写机制的，而且有肯定的触发条件(如下)，万一输出了 flushall 之后触发了重写机制，那么所有数据都会失落，而正式环境 redis 数据是始终在写入的，数据量是始终在变大的，随时都有触发重写条件的可能，所以得立刻关机，如果正好在你执行 flushall 的下一秒 触发了 aof 重写机制，那么数据就永远无奈复原了。
auto-aof-rewrite-percentage 100 #aof 文件大小比起上次重写时的大小, 增长率 100% 时, 重写
auto-aof-rewrite-min-size 64mb #aof 文件, 至多超过 64M 时, 重写复原数据步骤
- shutdown nosave
- 关上对应的 aof 文件 appendonly.aof，找到 flushall 对应的命令记录
*1
20839 $8
20840 flushall而后删除，保留
- 从新关上 redis 即可
倡议
以上说的办法只是实践，并且我在本地尝试过是可行的，线上环境状况要简单的多，保险起见，最好间接把 flushall 这种命令禁止掉，间接加在 reids.conf 中
rename-command FLUSHALL ""rename-command FLUSHDB""
rename-command KEYS ""
正文完
