内部群炸锅了，同事又删库了...( 二 ) 最近发生了一场生产事故

登录生产环境数据库，查看binlog是否开启：
SHOWVARIABLESLIKE'LOG_BIN%';
文章图片
从图中可以看到log_bin是处于ON的状态，说明binlog是开启的。
悬着的心终于放下了一大半，接下来就是想办法从binlog中把数据恢复就行了。
从上图中也可以看到log_bin_basename是/var/lib/mysql/bin-log ，说明binlog是存放在mysql所在的服务器的/var/lib/mysql目录下，文件是以bin-log开头，比如：bin-log.000001 。
登录mysql所在的服务器，进入到binlog所在的目录：
cd/var/lib/mysql查看binlog日志文件：

文章图片
binlog日志文件是滚动生成的，从图中看到现在已经有4个文件了。
通常情况下，生产环境的binlog会有成百上千个，这时候就需要确认我们需要的数据是在第几个binlog中了，下文也会讲怎么确定我们需要的是第几个。
因为我们删库是刚刚发生的事情，所以我们需要的数据大概率是在第4个文件中。
直接去查看第4个binlog文件，看到的全都是乱码，就像下面这样，这是因为binlog文件是二进制的。

文章图片
我们需要借助mysql官方提供的mysqlbinlog命令去才能正确解析binlog文件。
用mysqlbinlog命令可以打开binlog文件，但是一个binlog文件的大小可能有几百兆，要从几百兆日志中找到我们需要的日志，还是比较麻烦的。
还好mysqlbinlog命令提供一些参数选项可以让我们对binlog文件进行筛选，最常用的参数就是时间参数。 (下文也会对mysqlbinlog的详细用法进行说明)
经过和删库的研发人员确定，删库的时间大概是10:40 ，那我们就以这个时间点为参考，找前后5分钟的日志：
mysqlbinlog-v--start-datetime='2021-06-1010:35:00'--stop-datetime='2021-06-1010:45:00'bin-log.000004|grept_user
文章图片
从图中可以看到，这个时间点的日志确实包含我们删除数据的日志。
接下来我们就需要把这些日志整理一下，然后想办法恢复到数据库就可以了。
首先，把我们需要的日志单独保存到tmp.log文件中，方便下载到本地：
mysqlbinlog-v--start-datetime='2021-06-1010:35:00'--stop-datetime='2021-06-1010:45:00'bin-log.000004>tmp.log把tmp.log下载到本地，用文本编辑工具打开看一下，可以看到一堆伪sql：

文章图片
在上图的伪sql中：
@1表示第一个字段@2表示第二个字段其他的以此类推日志中包含的sql是一些伪sql ，并不能直接在数据库执行，我们需要想办法把这些伪sql处理成可在数据库执行的真正的sql 。
我们使用的文本编辑工具的批量替换功能，就像下面这样：

文章图片
最终处理好的sql就像是这样：

文章图片
把处理好的sql在测试数据库验证一下没问题后直接在生产库执行。 sql执行完以后，被误删除的数据就恢复回来了。
我们和删库的研发一起，把客户要求删除的6万多条数据重新给删除，算是完成了客户的要求。
至此，删库事件就暂时告一段落。不要问删库的研发受到了什么处分，问就是什么处分都没有。
04几点建议
删库跑路真的不只是一句玩笑话，如果真的不小心删库了而又无法找回数据的话，不仅仅是简单的罚款、扣绩效就完事了，甚至有可能会面临牢狱之灾。