一.产生背景 

     传统高可用架构不能预防误删 数据，主库的一个drop table命令，通过binlog传给所有从库和级联从库，导致整个集群的实例都会执行该命令

二. MySQL误删数据分类：

• 使用delete语句误删除数据行
• drop table或truncate table误删数据表
• drop database删除数据库
• rm命令误删整个MySQL实例

三.误删行

    Flashback工具闪回进行数据恢复

原理：修改binlog内容，拿回原库重放

注意事项:

        不要在主库执行这些操作

解决方法：

     找一个从库作为临时库，在临时库上执行这些操作，确认临时库的数据，再恢复主库

    防止出现对主库数据的二次伤害

预防措施：

•  将sql_safe_updates 参数设置为 on，如果忘记delete或者update中写where条件，或者没有包含索引字段，这条语句会执行报错
• 代码上线前，必须进行SQL审计

四.误删库 /表

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

假如有人中午12点误删一个库，恢复数据的流程如下：

• 取最近一次全量备份 ，假设这个库是一天一备，上次备份是当天0点
• 用备份恢复出一个临时库；
• 从日志备份里面，取出凌晨0点之后的日志
• 把这些日志，除了误删除数据的语句外，全部应用到临时库

 如何加速数据恢复？

      如果这个临时库有多个数据库，可以使用mysqlbinlog命令时，加上一个-database参数，用来指定误删表所在的库

    避免恢复数据时应用其他库日志的情况。

   在应用日志的时候，需要跳过12点误操作的那个语句的binlog

mysqlbinlog方法恢复数据还是不够快（恢复时间不可控）

• 如何误删表，最好就是只恢复这张表，重放这张表的操作，但是mysqlbinlog工具不能指定解析一个表的日志。
• 用mysqlbinlog解析出日志应用，应用日志的过程只能是单线程

延迟复制备库

• 延迟复制的备库是一种特殊的备库，通过change master to master_delay=N命令，可以指定这个备库持续保持跟主库有N秒延迟

  比如讲N设置为3600，如果主库上有数据被误删了，在1个小时候内发现这个误操作命令，这个命令在延迟复制的备库执行，这时候这个备库上执行stop salve命令

五.预防误删库/表的方法

1.  账号分离---- 只给开发同学DML权限 
2. 删除表，先给表改名，观察一段时间业务影响再删除，给表名加固定后缀（_to_be_deleted）,只删除固定后缀的表