Mysql误删数据解决方案及kill语句原理

mysql误删数据

  • 使用delete语句误删数据行
  • 使用drop table或者truncate table误删数据表
  • 使用drop database语句误删数据库
  • 使用rm误删mysql整个实例

对于误删行

  • 使用flashback工具闪回,把数据恢复回来。原理是修改binlog的内容,拿回原库重放,需要确保binlog_format=row和binlog_row_imsge=Full
  • 具体恢复时
    • 如果是insert,将binlog event类型是write_rows event改为delete_rows event。
    • 如果是delete则相反。
    • 如果是update,binlog里有数据修改前和修改后的值,对调这两行即可。
  • 多个事物也是按照以上原则倒叙执行。
  • 预防:把sql_safe_updates参数设置为on。这样一来,如果我们忘记在delete或者update语句中写where条件,或者where条件里面没有包含索引字段的话,这条语句的执行就会报错。

对于误删库/表

需要使用全量备份,加增量日志的方式。要求线上有定期的全量备份吗,并且实时备份binlog。

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

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

用备份恢复出一个临时库;

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

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

Mysql误删数据解决方案及kill语句原理

注意:

为了加速数据恢复,如果这个临时库上有多个数据库,你可以在使用mysqlbinlog命令时,加上一个–database参数,用来指定误删表所在的库。这样,就避免了在恢复数据时还要应用其他库日志的情况。

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

加速恢复的方法:备份恢复出临时实例之后,将这个临时实例设置成线上备库的从库,

Mysql误删数据解决方案及kill语句原理

一个系统不可能备份无限的日志,你还需要根据成本和磁盘空间资源,设定一个日志保留
的天数。如果你的DBA团队告诉你,可以保证把某个实例恢复到半个月内的任意时间点,这就表示备份系统保留的日志时间就至少是半个月。

虽然“发生这种事,大家都不想的”,但是万一出现了误删事件,能够快速恢复数据,将损失
降到最小,也应该不用跑路了。而如果临时再手忙脚乱地手动操作,最后又误操作了,对业务造成了二次伤害,那就说不过去了。

延迟复制备库

  • 如果一个库的备份特别大,或者误操作的时间距离上一个全量备份的时间较长,比如一周一备的实例,在备份之后的第6天发生误操作,那就需要恢复6天的日志,这个恢复时间可能是要按天来计算的。
  • 延迟复制的备库是一种特殊的备库,通过 CHANGE MASTER TO MASTER_DELAY = N命令,可以指定这个备库持续保持跟主库有N秒的延迟。
  • 比如你把N设置为3600,这就代表了如果主库上有数据被误删了,并且在1小时内发现了这个误操作命令,这个命令就还没有在这个延迟复制的备库执行。这时候到这个备库上执行stopslave,再通过之前介绍的方法,跳过误操作命令,就可以恢复出需要的数据。

对于rm删除数据

只要不是恶意地把整个集群删除,而只是删掉了其中某一个节点的数据的话,HA系统就会开始工作,选出一个新的主库,从而保证整个集群的正常工作。这时,你要做的就是在这个节点上把数据恢复回来,再接入整个集群。

当然了,现在不止是DBA有自动化系统,SA(系统管理员)也有自动化系统,所以也许一个批量下线机器的操作,会让你整个MySQL集群的所有节点都全军覆没。应对这种情况,我的建议只能是说尽量把你的备份跨机房,或者最好是跨城市保存。Kill sql语句

Mysql误删数据解决方案及kill语句原理

Mysql误删数据解决方案及kill语句原理

扫一扫手机访问