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

最近发生了一场生产事故，误删了金主爸爸10多万条核心数据，直接导致服务崩溃....

文章图片
图片来自Pexels
01事件起因
我们的系统中有数据导入的功能，可以把特定的格式的excel数据导入到系统中来。
由于客户电脑的文件比较多，很多文件的名字也比较相近，客户在导入excel时选错了文件。
这个错误的excel文件的格式恰好能被系统解析，客户也没及时发现导错了文件，所以就将6万多条没用的数据导入到了系统中!

文章图片
这6万多条数据对系统来说就是无用的数据，不会影响系统的运行，最多也就是占用一点数据库空间而已。
客户只需要把正确的excel重新导入，就可以继续完成他的业务了。但是，客户是一个重度强迫症患者，他觉得在管理平台看到这6万多条没用的数据令他抓狂。
客户想要把这些数据删除，我们系统又没有提供批量删除功能，只能单个删除，这无疑是一个巨大的工作量。
客户就通过客服部门找到了研发团队，想让我们研发人员从数据库中直接删除。
02删库经过
虽然在生产环境直接操作数据库明显是违规操作，但客户的要求又不得不满足，谁让人家是爸爸呢。

文章图片
由于生产环境的数据和表结构属于商业机密，我们讨论的重点也不在于数据和表结构，而是数据恢复的思路。
所以我在测试环境新建了用户表，导入了一些测试数据，当作是生产环境进行操作。
研发人员登录生产数据库，执行如下sql ，找到了这6万多条错误数据：
select*fromt_userwhereage>18anddeptid=100;在确认这6万多条数据确实是错误导入的数据后就准备开始删除。由于表里面没有逻辑删除字段，所以只能进行物理删除。
需要删除的数据已经确定，通常情况下把sql中的select*替换为delete去执行，出错的机率会小一点。
但是，研发人员并没有去改原来的sql ，而是重新写了一个删除语句并且执行：
deletefromt_userwhereage>18;问题就这样出现了，在新写的删除语句中缺少了deptid=100的条件。不要问我为什么删除之前没有备份，这都是血泪的教训。
【内部群炸锅了，同事又删库了...】重新查表后发现误删了10多万条数据，生产环境中，很多业务都依赖这个表，算是系统的核心表。
虽然是只删除了10万条数据，但系统的很多功能无法正常使用，其实和删库没啥区别了!

文章图片
研发人员发现删库后，第一时间报告给了领导(居然没有第一时间跑路) 。
领导当机立断，要求系统停止运行，给所有客户发送停服通知，打开所有客服通道，处理客户投诉和答疑，同时，也安排研发人员进行数据找回，要求尽快搞定。
03数据找回
我们找到删库的研发人员询问他有没有备份，他的回答是没有。
我们又去咨询运维的同事，看看生产环境有没有开启数据库定期自动备份，运维的回答也是没有。
事情比较难办了，只能把希望寄托于mysql的binlog了。
binlog二进制日志文件，数据库的insert、delete、update、create、alter、drop等写入操作都会被binlog记录(下文对binlog有详细介绍) 。
binlog记录日志是需要开启配置的，希望生产环境的mysql数据库开启了binlog日志，否则只能找专业的磁盘数据恢复的第三方公司了。