误删数据后只能跑路了吗?（误删数据后只能跑路了吗苹果）

我们知道传统的高可用架构是不能预防误删数据的，因为主库的一个drop table命令，会通过 binlog 传给所有从库和级联从库，进而导致整个集群的实例都会执行这个命令。虽然大多数的数据被删案例，都是运维或者DBA 背锅的。但实际上，只要有数据操作权限的同学，都有可能踩到误删数据这条线。

那么在误删数据前后，我们可以做些什么来减少误删数据带来的风险和损失。

为了能够快速应对，我们需要对MySQL误删数据进行简单的分类：

• 使用 delete 语句误删数据行；

• 使用 drop table 或者 truncate table 语句误删数据表；

• 使用 drop database 语句误删数据库；

• 使用 rm 命令误删整个 MySQL 实例。

使用 delete 语句误删了数据行：可以用 Flashback 工具通过闪回把数据恢复回来。使用该工具的前提是 binlog_format=row 和 binlog_row_image=FULL。闪回的原理是对binlog进行修改，然后回放。

使用 drop table 或者 truncate table 语句误删数据表：这种情况下想要恢复数据，就需要使用全量备份 + 增量binlog日志。该方案需要有定期全量备份，并有备份完成后drop或truncate命令执行期间的所有binlog。所以说备份大于一切，生产环境一定要备份。

使用 drop database 语句误删数据库：同样需要通过全量备份来恢复数据，并利用binlog来恢复增量数据。还有一种方案就是搭建延迟同步库，通过 CHANGE MASTER TO MASTER_DELAY = N 命令，可以指定这个备库持续保持跟主库有 N 秒的延迟，然后利用这个时间差来恢复数据，或者直接中断同步，手动追主库数据到drop前，再将业务流量直接写入延迟库。

使用 rm 命令误删整个 MySQL 实例：rm删除实例这种该情况，就算是拿全量备份恢复也还是会丢失备份时刻到执行rm命令期间的增量数据。最好的解决方案就是有一套高可用架构，业务直接切到另一个节点，故障节点重做恢复后再加入到集群中。

上面说了那么多，有什么好用的工具呢？

这里强烈推荐my2sql，该工具可针对表级别的delete，update快速恢复数据，可过滤时间，点位，操作类型，具体的表等生产正常的SQL以及回滚SQL。

当然，在有应对预案的同时，如何才能防范于未然，提前预防呢？

那就是权限控制，严格控制账号的权限，遵循最小权限原则。有条件的可以研发堡垒，二次审批确认，或者命令改写等。