AI 助理
文档备案控制台
开发者社区 数据库 文章 正文

MySQL的delete误操作的快速恢复方法

2018-11-04 16119
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL DuckDB 分析主实例，基础系列 4核8GB
RDS MySQL DuckDB 分析主实例，集群系列 4核8GB
RDS AI 助手，专业版
简介： 如果我们在数据库中不小心执行了类似“delete from t1”这样的不带where条件的语句，那么整张表的数据就全被删除了，如何在最短的时间恢复被删除的数据就显得十分关键。下面来演示如何通过binlog来快速恢复表数据。

如果我们在数据库中不小心执行了类似“delete from t1”这样的不带where条件的语句，那么整张表的数据就全被删除了，如何在最短的时间恢复被删除的数据就显得十分关键。下面来演示如何通过binlog来快速恢复表数据。
一、误删除表数据
一张person表的结构和数据如下，不小心误删除了整张表的数据：
image

二、根据误操作时间定位binlog位置
找到数据库的binlog存放位置，当前正在使用的binlog文件里面就有我们要恢复的数据。一般生产环境中的binlog文件都是几百M乃至上G的大小，我们不能逐行去找被删除的数据在什么位置，所以记住误操作的时间很重要，我们可以通过mysqlbinlog命令的--start-datetime参数快速定位数据位置。上图的误操作时间为20181104151800，解析出的binlog内容如下：

[root@cos7-jiang mysql]# mysqlbinlog -vv --start-datetime='2018-11-04 15:18:00' on.000004|more
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#700101  8:00:00 server id 1  end_log_pos 120 CRC32 0x199f2da4     Start: binlog v 4, server v 5.6.42-log created 700101  8:00:
00
# Warning: this binlog is either in use or was not closed properly.
BINLOG '
AAAAAA8BAAAAdAAAAHgAAAABAAQANS42LjQyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAaQt
nxk=
'/*!*/;
# at 120
#181104 15:18:37 server id 1  end_log_pos 192 CRC32 0x2224f8de     Query    thread_id=16    exec_time=0    error_code=0
SET TIMESTAMP=1541315917/*!*/;
SET @@session.pseudo_thread_id=16/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 192
#181104 15:18:37 server id 1  end_log_pos 252 CRC32 0x65fbbe3b     Table_map: `test`.`person` mapped to number 85
# at 252
#181104 15:18:37 server id 1  end_log_pos 435 CRC32 0x005d1b39     Delete_rows: table id 85 flags: STMT_END_F

BINLOG '
TZ3eWxMBAAAAPAAAAPwAAAAAAFUAAAAAAAEABHRlc3QABnBlcnNvbgAGAw/+DwMDBgoA/gEKAD47
vvtl
TZ3eWyABAAAAtwAAALMBAAAAAFUAAAAAAAEAAgAG/8ABAAAAAmppATEDd2VyqEA0AGpqyADAAgAA
AANsdW8BMQN3ZXKcQjQAJ2zZAMADAAAAAnl1ATAEamVndfombwA3JyEBwAQAAAACZGEBMAdiZWlq
aW5nOgZQAFfZQADABQAAAAJnagEwB2JlaWppbmcSBlAAh+jOAMAGAAAABHlhbmcBMAduYW5qaW5n
cg5MAIdSqwo5G10A
'/*!*/;
### DELETE FROM `test`.`person`
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='ji' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @3='1' /* STRING(1) meta=65025 nullable=1 is_null=0 */
###   @4='wer' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @5=3424424 /* INT meta=0 nullable=1 is_null=0 */
###   @6=13134442 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
###   @1=2 /* INT meta=0 nullable=0 is_null=0 */
###   @2='luo' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @3='1' /* STRING(1) meta=65025 nullable=1 is_null=0 */
###   @4='wer' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @5=3424924 /* INT meta=0 nullable=1 is_null=0 */
###   @6=14248999 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
###   @1=3 /* INT meta=0 nullable=0 is_null=0 */
###   @2='yu' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
###   @4='jegu' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @5=7284474 /* INT meta=0 nullable=1 is_null=0 */
###   @6=18949943 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
###   @1=4 /* INT meta=0 nullable=0 is_null=0 */
###   @2='da' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
###   @4='beijing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @5=5244474 /* INT meta=0 nullable=1 is_null=0 */
###   @6=4249943 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
###   @1=5 /* INT meta=0 nullable=0 is_null=0 */
###   @2='gj' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
###   @4='beijing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @5=5244434 /* INT meta=0 nullable=1 is_null=0 */
###   @6=13559943 /* INT meta=0 nullable=1 is_null=0 */
### DELETE FROM `test`.`person`
### WHERE
###   @1=6 /* INT meta=0 nullable=0 is_null=0 */
###   @2='yang' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @3='0' /* STRING(1) meta=65025 nullable=1 is_null=0 */
###   @4='nanjing' /* VARSTRING(10) meta=10 nullable=1 is_null=0 */
###   @5=4984434 /* INT meta=0 nullable=1 is_null=0 */
###   @6=178999943 /* INT meta=0 nullable=1 is_null=0 */
# at 435
#181104 15:18:37 server id 1  end_log_pos 466 CRC32 0xab85d971     Xid = 197
COMMIT/*!*/;
# at 466
#181104 15:19:38 server id 1  end_log_pos 538 CRC32 0x8b9e1093     Query    thread_id=16    exec_time=0    error_code=0
SET TIMESTAMP=1541315978/*!*/;
BEGIN
/*!*/;
# at 538
#181104 15:19:38 server id 1  end_log_pos 598 CRC32 0xb1679f78     Table_map: `test`.`person` mapped to number 85
# at 598
#181104 15:19:38 server id 1  end_log_pos 656 CRC32 0xa5d7a2d6     Write_rows: table id 85 flags: STMT_END_F

通过上面的命令可以比较方便地逐页寻找被删除的数据，我们应该要找到被删除的数据在binlog中的起始和终止位置点，例如上面的被删除数据的位置点在192和435之间，这样我们可以保证在这两个位置之间只有我们需要的待恢复的数据，而没有其他数据。
本次测试的数据量很小，如果一张表有数十万行数据被误删除，我们通过上面的方式找位置点是很费时间的。这时可以通过下面的两个命令锁定起始和终止位置：
确定起始位置点：

mysqlbinlog -vv --start-datetime='2018-11-04 15:18:00' on.000004| head -1000 |more

确定终止位置点：

mysqlbinlog -vv --start-datetime='2018-11-04 15:18:00' --stop-datetime='2018-11-04 15:20:00' on.000004| tail -1000 |more

我们只看binlog输出的前N行和后N行，来找到起始和终止位置，这样可以大大节省时间。
三、将binlog里的delete语句转化为insert语句
Binlog是二进制文件，我们可以先把待恢复数据导出为可阅读文本：

mysqlbinlog -vv --start-position=192 --stop-position=435 on.000004 |grep ^"###" >/tmp/bin_data

接下来就是处理/tmp/bin_data文本，将里面的delete语句转化为insert语句，可以通过下面的语句实现转化：

cat /tmp/bin_data | sed -n '/###/p' | sed 's/### //g;s/\/\*.*/,/g;s/DELETE FROM/INSERT INTO/g;s/WHERE/SELECT/g;' |sed -r 's/(@6.*),/\1;/g' | sed 's/@[1-9]=//g' | sed 's/@[1-9][0-9]=//g' >/tmp/person.sql

_1

四、将insert语句导入数据库中
Delete语句误操作只会删除表数据，而表结构还在。所以我们可以直接将文本里的insert语句导入到数据库中，即可完成数据恢复：

mysql -h127.0.0.1 -P3306 -uroot -p123 < /tmp/person.sql

补充和总结：
1、以上操作只针对delete误操作有效，且binlog模式是行模式；如果是drop或者truncate语句造成的误操作，亦或者binlog不是row模式，在binlog文件里是找不到完整的被删除数据，这个时候可以考虑通过备份进行恢复；
2、如果在误操作很久之后才意识到数据被误删除，记不清误操作的大致时间，那么可以找到误操作所在的binlog文件，将binlog解析为可阅读文本形式，然后借助文本编辑命令找误操作位置，再恢复；如果这种方式很慢的话，可以考虑通过备份恢复，或者从别的环境中导出这张表的数据再导入到当前环境中；
3、Mysqlbinlog命令重要参数
-vv 将二进制转换为可阅读文本
--start-datetime 起始时间
--stop-datetime 终止时间
--start-position 起始位置
--stop-position 终止位置
--base64-output=decode-row 查看最底层DML语句数据模块，前提是数据库参数binlog_rows_query_log_events打开
4、熟悉linux的文本编辑命令，如grep、sed、awk等
5、虽然binlog2sql工具也可以快速解析binlog，生成回滚SQL，但只要清楚上面的命令和操作流程，恢复速度也不会比binlog2sql慢很多，更何况如果环境没有安装这个工具。

文章标签：
云数据库 RDS MySQL 版
关系型数据库
数据库
Perl
MySQL
SQL
Linux
关键词：
云数据库 RDS MySQL 版delete
云数据库 RDS MySQL 版方法
云数据库 RDS MySQL 版误操作
云数据库 RDS MySQL 版恢复
云数据库 RDS MySQL 版恢复方法
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发，帮助IT从业者们通过“阿里云Web应用上云解决方案”，了解一个企业级Web应用上云的常见架构，了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品：云数据库RDS MySQL 版 阿里云关系型数据库RDS（Relational Database Service）是一种稳定可靠、可弹性伸缩的在线数据库服务，提供容灾、备份、恢复、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
未央&amp;
目录
相关文章
大数据文摘
|
8月前
|
人工智能 运维 关系型数据库
数据库运维：mysql 数据库迁移方法-mysqldump
本文介绍了MySQL数据库迁移的方法与技巧，重点探讨了数据量大小对迁移方式的影响。对于10GB以下的小型数据库，推荐使用mysqldump进行逻辑导出和source导入；10GB以上可考虑mydumper与myloader工具；100GB以上则建议物理迁移。文中还提供了统计数据库及表空间大小的SQL语句，并讲解了如何使用mysqldump导出存储过程、函数和数据结构。通过结合实际应用场景选择合适的工具与方法，可实现高效的数据迁移。
大数据文摘
1405 1
1243767626601764
|
5月前
|
SQL 关系型数据库 MySQL
Mysql数据恢复—Mysql数据库delete删除后数据恢复案例
本地服务器，操作系统为windows server。服务器上部署mysql单实例，innodb引擎，独立表空间。未进行数据库备份，未开启binlog。 人为误操作使用Delete命令删除数据时未添加where子句，导致全表数据被删除。删除后未对该表进行任何操作。需要恢复误删除的数据。 在本案例中的mysql数据库未进行备份，也未开启binlog日志，无法直接还原数据库。
1243767626601764
488 2
游客kufrkwrbkmpsa
|
11月前
|
SQL 存储 关系型数据库
【YashanDB知识库】共享从 MySQL异常处理CONTINUE HANDLER的改写方法
【YashanDB知识库】共享从 MySQL异常处理CONTINUE HANDLER的改写方法
游客kufrkwrbkmpsa
256 2
蓝易云
|
6月前
|
存储 关系型数据库 MySQL
MySQL数据库中进行日期比较的多种方法介绍。
以上方法提供了灵活多样地处理和对比MySQL数据库中存储地不同格式地日子信息方式。根据实际需求选择适当方式能够有效执行所需操作并保证性能优化。
蓝易云
653 10
蓝易云
|
7月前
|
SQL Oracle 关系型数据库
比较MySQL和Oracle数据库系统，特别是在进行分页查询的方法上的不同
两者的性能差异将取决于数据量大小、索引优化、查询设计以及具体版本的数据库服务器。考虑硬件资源、数据库设计和具体需求对于实现优化的分页查询至关重要。开发者和数据库管理员需要根据自身使用的具体数据库系统版本和环境，选择最合适的分页机制，并进行必要的性能调优来满足应用需求。
蓝易云
383 11
蓝易云
|
9月前
|
SQL 数据采集 关系型数据库
实现MySQL与SQL Server之间数据迁移的有效方法
总的来说，从MySQL到SQL Server的数据迁移是一个涉及到很多步骤的过程，可能会遇到各种问题和挑战。但只要精心规划、仔细执行，这个任务是完全可以完成的。
蓝易云
648 18
蓝易云
|
10月前
|
SQL 关系型数据库 MySQL
【MySQL】SQL分析的几种方法
以上就是SQL分析的几种方法。需要注意的是，这些方法并不是孤立的，而是相互关联的。在实际的SQL分析中，我们通常需要结合使用这些方法，才能找出最佳的优化策略。同时，SQL分析也需要对数据库管理系统，数据，业务需求有深入的理解，这需要时间和经验的积累。
蓝易云
346 12
青云交（Java大数据AI云原生Python）
|
10月前
|
SQL 关系型数据库 MySQL
大数据新视界--大数据大厂之MySQL数据库课程设计：MySQL 数据库 SQL 语句调优方法详解（2-1）
本文深入介绍 MySQL 数据库 SQL 语句调优方法。涵盖分析查询执行计划，如使用 EXPLAIN 命令及理解关键指标；优化查询语句结构，包括避免子查询、减少函数使用、合理用索引列及避免 “OR”。还介绍了索引类型知识，如 B 树索引、哈希索引等。结合与 MySQL 数据库课程设计相关文章，强调 SQL 语句调优重要性。为提升数据库性能提供实用方法，适合数据库管理员和开发人员。
青云交（Java大数据AI云原生Python）
377 11
游客beejssedmb2sq
|
8月前
|
关系型数据库 MySQL
MySQL字符串拼接方法全解析
本文介绍了四种常用的字符串处理函数及其用法。方法一：CONCAT，用于基础拼接，参数含NULL时返回NULL；方法二：CONCAT_WS，带分隔符拼接，自动忽略NULL值；方法三：GROUP_CONCAT，适用于分组拼接，支持去重、排序和自定义分隔符；方法四：算术运算符拼接，仅适用于数值类型，字符串会尝试转为数值处理。通过示例展示了各函数的特点与应用场景。
游客beejssedmb2sq
988 0
蓝易云
|
10月前
|
Ubuntu 关系型数据库 MySQL
在Ubuntu系统的Docker上安装MySQL的方法
以上的步骤就是在Ubuntu系统的Docker上安装MySQL的详细方法，希望对你有所帮助！
蓝易云
1098 12

热门文章

最新文章

  • 1
    阿里云DTS踩坑经验分享系列｜如何使用DTS进行MySQL->ClickHouse同步
  • 2
    MySQL · 引擎特性 · InnoDB 大字段压缩
  • 3
    mysql远程连接数据库很慢
  • 4
    MySQL表连接（内连接、交叉连接、外连接、联合查询）
  • 5
    大数据 | （五）通过Sqoop实现从MySQL导入数据到HDFS
  • 6
    浅析MySQL优化器统计信息
  • 7
    断电了，MySQL也不会丢失数据
  • 8
    一分钟安装mysql
  • 9
    mysql用户授权与权限撤销
  • 10
    安装MySQL5.1.24
  • 1
    MySQL数据库索引的数据结构？
    222
  • 2
    MySQL 核心知识与索引优化全解析
    181
  • 3
    MySQL 核心知识与性能优化全解析
    171
  • 4
    字节面试： MySQL 百万级 导入发生的 “死锁” 难题如何解决？“2序4拆”，彻底攻克
    583
  • 5
    MYSQL八股
    89
  • 6
    MySQL功能模块探秘：数据库世界的奇妙之旅
    227
  • 7
    如何实现MySQL百万级数据的查询？
    399
  • 8
    mysql事务隔离级别
    219
  • 9
    MySQL 分库分表 + 平滑扩容方案 （秒懂+史上最全）
    1867
  • 10
    在MySQL中处理高并发和负载峰值的关键技术与策略
    366

    • 相关课程

    更多
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 阿里云数据库产品家族及特性
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • PolarDB MySQL引擎重磅功能及产品能力盛大发布
  • 阿里云MySQL云数据库产品体系介绍
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL

    • 推荐镜像

    更多
  • mysql
    • 下一篇
    第五届伏魔挑战赛如约来袭，诚邀各路高手来战！