《MySQL——恢复数据-误删行、表、库》

目录
误删行
事前预防误删行数据方法
误删表/库
延迟复制备库
事前预防误删库/表方法

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

MySQL相关的误删除数据分类：

1、使用delete语句误删数据行

2、使用drop table 或者 truncate table 语句误删数据表

3、使用drop database语句误删数据库

4、使用rm命令误删整个MySQL实例

误删行

若使用delete语句误删数据行，可以用Flashback工具通过闪回把数据恢复。

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

前提：binlog_fromat = row 和binlog_row_image = FULL

具体措施：

1、对于insert语句，对应的binlog event 类型为WrIte_rows event，将其改为Delete_rows event

2、同理，对于delete，将Delete_rows event 改为Write_rows event

3、对于Update_rows，binlog记录了数据行修改前和修改后的值，对调两行位置即可

如果误操作是多个，如：

(A)delete ...
(B)insert ...
(C)update ...

若要恢复这三个事务之前状态，用Flashback工具解析binlog后，写回主库：

(reverse C)update ...
(reverse B)delete ...
(reverse A)insert ...

恢复数据的比较安全的做法是恢复出一个备库，或者找一个从库作为临时库，在这个临时库上执行这个操作，然后再将确认过的临时库的数据，恢复回主库。

这是由于发现数据问题时间比较晚，导致会有在误操作的基础上的逻辑，如果单独恢复这个几行数据，会对数据造成二次破坏。

事前预防误删行数据方法

1、把sql_safe_updates参数设置为on。这样如果忘记在delete或者update语句中写where条件，或者where条件里没有包含索引字段，语句执行报错

2、代码上线前，必须经过SQL审计

误删表/库

需要删除一个表时，delete全表很慢，需要生成回滚日志、写redo、写binlog，所以常常使用truncate table 或者 drop table。

直接drop表和delete每行的最大区别就是，binlog对delete有详细的删除行内容，可是drop表后binlog就只有一个drop语句，恢复不了数据。

使用truncate/drop误删除数据时的恢复方法：使用全量备份，加增量日志。要求对线上有定期的全量备份，并且实时备份binlog。

如果中午误删了库，恢复数据流程如下：

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

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

3、从日志被分离，取出0点之后的日志

4、把这些日志，除了误删除的数据的语句外，全部应用到临时库
在这里插入图片描述

加速恢复数据

1、如果临时库有多个数据库，可以指定误删表所在的库，这样就避免了恢复数据时还要应用其他库日志。

2、应用日志时，跳过误操作的语句

不过这样使用mysqlbinlog方法恢复数据不够快。

mysqlbinlog恢复数据不够快的原因：不能指定特定数据表、单线程操作

另外的加速方法

在用备份恢复出临时实例之后，将这个临时实例设置成线上备库的从库。

具体流程：

1、在start slave 之前，执行change replication filter replicate_do_table = (tbl_name),让临时库只同步误操作的表

2、可以使用并行复制技术，加速数据恢复
在这里插入图片描述

延迟复制备库

如果一个库备份很大，或者误操作的时间举例上一个全备份的时间较长，可以搭建延迟复制的备库缩短恢复数据恢复需要的时间。

一般的主备复制结构存在问题：如果主库有个表被误删了，这个命令很快也会被发给所有从库，进而导致所有从库的数据表也都一起被误删。

可以主动加大同步延迟，通过CHANGE MASTER TO MASTER_DELAY = N 命令，指定这个备库始终与主库有N秒延迟。如果把N设置为3600，代表如果主库上有数据被误删了，并且在1h之内发现了这个误操作，该命令此时没有在延迟复制的备库执行，所以可以到备库上stop slave，然后跳过误操作命令，恢复数据。