从删库到跑路

今天写写数据误删怎么办 = = 

一   预防 大于 恢复

       删了之后怎么恢复数据，那都是事后操作，在事情发生前，如何避免问题发生，用较少的资源合理有效避免降低风险才是王道，下面聊聊如何避免 误删数据。

1  权限

一般情况下，操作线上数据的所有入口都会有权限，一般都会给开发人员线上查询的权限，像这种的，就完全杜绝删除更改数据操作语句，做上限制，不给更改数据的权限。

如果要修复线上数据，一般都是有审批流的（其实一般审核的都不看），所以也要做限制，sql_safe_updates 参数设置为 on 避免无条件删除，显示更改数据行数，删除大量数据警告等。

2 不要根据条件修改

如果出现线上刷数据，尽量不要根据条件修改，例如   修改  名字=王大锤  的语文成绩 = 50 这样很容易出错，比如在修改之前突然 又有个名字是王大锤的，就和预计的不一样，要根据id修改，或者唯一编码。

3 备份是王道，小心秋后算账

如果修改的数据量小，甭管是删除还是更新某个字段，一定要先把要修改的数据备份，一般删除都是 用标志删除的方式，也不要真删除数据（容易出问题），先备份好数据，避免当时修改完了 过了 6个月 业务秋后算账，为啥数据没了，或者各种问题，有档可查，也好解释，如果是大量数据的更改，还是请DBA全量备份吧（快照的备份比较快）

4 改名字比删除更明智

一般如果要删除某个表，改个名字吧，站着空间就站着，一周后没啥事备份出来

5 数据库备份

无论是 误删行数据 误删 表数据  或者删库了，被攻击了，都不用怕   定期全量异地备份数据库+binlog回复，全量频率表主要看情况，这个一般都有DBA来做，基操。

二 真删了  咋整？

1 删除了某行 或者更新错了某些数据 ，旧数据也不记得啥样了，怎么办？

Flashback 恢复数据的原理，是修改 binlog 的内容，拿回原库重放。而能够使用这个方案的前提是，需要确保 binlog_format=row 和 binlog_row_image=FULL。

具体恢复数据时，对单个事务做如下处理：

对于 insert 语句，对应的 binlog event 类型是 Write_rows event，把它改成 Delete_rows event 即可；

同理，对于 delete 语句，也是将 Delete_rows event 改为 Write_rows event；

而如果是 Update_rows 的话，binlog 里面记录了数据行修改前和修改后的值，对调这两行的位置即可。

如果误操作不是一个，而是多个，会怎么样呢？比如下面三个事务：

(A)delete ...

(B)insert ...

(C)update ...

现在要把数据库恢复回这三个事务操作之前的状态，用 Flashback 工具解析 binlog 后，写回主库的命令是：

(reverse C)update ...

(reverse B)delete ...

(reverse A)insert ...

也就是说，如果误删数据涉及到了多个事务的话，需要将事务的顺序调过来再执行。

2  删库了  删表了

相信你现在脑袋懵懵的，

这种情况下，要想恢复数据，就需要使用全量备份，加增量日志的方式了。这个方案要求线上有定期的全量备份，并且实时备份 binlog。

在这两个条件都具备的情况下，假如有人中午 12 点误删了一个库，恢复数据的流程如下：

1 取最近一次全量备份，假设这个库是一天一备，上次备份是当天 0 点；

2 用备份恢复出一个临时库；

3 从日志备份里面，取出凌晨 0 点之后的日志；

4 把这些日志，除了误删除数据的语句外，全部应用到临时库。

三  总之

不要慌，业务场景复杂，有时候业务还在跑，也不一定是直接恢复就能解决问题的，所以首先要冷静，然后按照这个个思路去想解决方案

1  紧急止损，避免问题扩张

数据误删对业务有没有影响？先保证业务正常，数据删除会不会导致其他问题？先要止损。

2 修复方案，要稳，要YAO人

毕竟删除数据如果造成很严重后果，先要联系DBA，要有同事，大家一起想办法，毕竟全量备份恢复和binlog恢复一般也不是你能操作的，严重的话开会研究方案，要稳，避免恢复了还出现别的问题。

写sql的时候好好看看吧，尤其是delete ，没啥事别真删除数据。