误删库不再跑路！

一般情况如果在大公司删库删表这种情况基本上不会遇到，毕竟给咱们开发的账号不会开这么高的权限。但是在小公司的话就不一定，没这么规范，要是咱们手抖一下，不小心删错了咋办？

比如你delete错了,把别的行给删了。然后如果你的数据库binlog配置是

binlog_format = row 和 binlog_row_image = FULL

比如你的delete语句对应的binlog event 类型是Delete_rows event然后将它改成Write_rows event;

把修改的binlog拿回原库重放就行了。

如果是你update的话，那binlog里面也是记录了数据修改前和修改后的值的，你只要对调这两行数据的位置就行。

推荐使用Flashback工具，工具的原理就是我上面说的那样。

还有这种操作不建议在主库上执行，一般情况是备份一个库，或者在哪个从库上执行这些操作，确认没问题的然后再回复主库确保主库的安全。

但是有些哥们可能比较猛，他可能是drop或者truncate哪个table了或者是drop database了。这种情况下binlog记得只会是一个drop/truncate语句，所以用上面的方法是搞不定的。

咋办呢，找之前的全量备份，没得话...你懂得

找到之前的全量备份然后配合增量的日志恢复。流程就是：

1.找到最近一次的全量备份。比如是2019-3-25 晚上11点

2.通过这个备份恢复出一个临时库

3.在日志备份里面找到2019-3-25 晚上11点之后的日志

4.将这些日志除了误删除的那个语句全部应用到临时库上

第4条这个操作，如果你的数据库实例用了GTID模式，就先set gtid_next=(你的删除语句的GTID);begin;commit;

如果没用这个模式，那只能是应用到这个删除语句之前先用-stop-position参数执行到这个语句之前，然后-start-position开始这个语句之后的执行。

我们做主从备份，为了防止误删数据导致的问题，可以搞一个延迟一小时的从库，就比如我们是一个星期备份一次的，那我们如果在第七天出了什么错，需要恢复的话，那得跑多久啊！所以弄一个特殊的备库，通过

CHANGE MASTER TO MASTER_DELAY = N

来设置这个备库和主库有N秒的延迟，这样发现主库误操作了，马上再这个备库上执行 stop slave，然后通过上面的方法跳过误删除的命令，恢复数据！

甚至还有更猛的哥们，他可能在服务器上在操作啥，比如像删除一些文件，但是搞错了，rm删了整个数据库实例....

没事别怕.....咱一般至少数据库会搞个主从的...咱删了主库，从库能顶上，对吧！项目还能跑呢！我们再从备份搞过来恢复一下咱们的主库。不怕不用跑路！

这都是发生了之后的补救措施，咱们最好就是预防一下，比如一般来说没事就不用这么高权限的账号，然后写sql的时候最好准备多个脚本，比如备份脚本，执行脚本，回滚脚本等。防范于未然！

如有错误欢迎指正！

个人公众号:yes的练级攻略