Mysql通过mysqlbinlog工具恢复误删除数据

一、误删除的数据恢复

1、配置/etc/my.cnf,添加如下参数打开binlog

server_id=181

log_bin=binlog

binlog_format=ROW

2、创建表及测试数据

mysql> create table test(id int(4),name varchar(22));

Query OK, 0 rows affected (0.07 sec)

insert into test values(1,'a');

insert into test values(2,'c');

insert into test values(3,'d');

mysql> select * from test;

+------+------+

| id   | name |

+------+------+

|    1 | a    |

|    2 | c    |

|    3 | d    |

+------+------+

3 rows in set (0.00 sec)

3、现在将表数据及表删除

mysql> delete from test;

Query OK, 3 rows affected (0.02 sec)

mysql> drop table test;

Query OK, 0 rows affected (0.04 sec)

4、挖掘binlog日志

报错：

[root@ttt data]# mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /mysql/data/binlog.000001 >kkk.sql

ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35

解决：指向绝对路径可以

/mysql/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=decode-rows /mysql/data/binlog.000001 >kkk.sql

binlog日志:

# at 219

#171016 22:49:16 server id 181  end_log_pos 336 CRC32 0x379b4da4 Query thread_id=3 exec_time=0 error_cod

e=0

use `bhs`/*!*/;

SET TIMESTAMP=1508165356/*!*/;

SET @@session.pseudo_thread_id=3/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1436549152/*!*/;

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/*!*/;

create table test(id int(4),name varchar(22))

/*!*/;

# at 336

#171016 22:50:16 server id 181  end_log_pos 401 CRC32 0xbd9a58a5 Anonymous_GTID last_committed=1 sequence_

number=2

SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;

# at 401

#171016 22:50:16 server id 181  end_log_pos 472 CRC32 0x1a8c6154 Query thread_id=3 exec_time=0 error_cod

e=0

SET TIMESTAMP=1508165416/*!*/;

BEGIN

/*!*/;

# at 472

#171016 22:50:16 server id 181  end_log_pos 521 CRC32 0x99399010 Table_map: `bhs`.`test` mapped to number 219

# at 521

#171016 22:50:16 server id 181  end_log_pos 563 CRC32 0xb3366604 Write_rows: table id 219 flags: STMT_END_F

### INSERT INTO `bhs`.`test`

### SET

###   @1=1 /* INT meta=0 nullable=1 is_null=0 */

###   @2='a' /* VARSTRING(22) meta=22 nullable=1 is_null=0 */

# at 563

#171016 22:50:16 server id 181  end_log_pos 594 CRC32 0xb69dc2ef Xid = 10

COMMIT/*!*/;

# at 594

#171016 22:50:16 server id 181  end_log_pos 659 CRC32 0x981028de Anonymous_GTID last_committed=2 sequence_

number=3

SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;

# at 659

#171016 22:50:16 server id 181  end_log_pos 730 CRC32 0x9aaee2fb Query thread_id=3 exec_time=0 error_cod

e=0

SET TIMESTAMP=1508165416/*!*/;

BEGIN

/*!*/;

# at 730

#171016 22:50:16 server id 181  end_log_pos 779 CRC32 0xaf1b75d4 Table_map: `bhs`.`test` mapped to number 219

# at 779

#171016 22:50:16 server id 181  end_log_pos 821 CRC32 0x31527c07 Write_rows: table id 219 flags: STMT_END_F

### INSERT INTO `bhs`.`test`

### SET

###   @1=2 /* INT meta=0 nullable=1 is_null=0 */

###   @2='c' /* VARSTRING(22) meta=22 nullable=1 is_null=0 */

# at 821

#171016 22:50:16 server id 181  end_log_pos 852 CRC32 0x5f635042 Xid = 11

COMMIT/*!*/;

# at 852

#171016 22:50:21 server id 181  end_log_pos 917 CRC32 0x89e9ae79 Anonymous_GTID last_committed=3 sequence_

number=4

SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;

# at 917

#171016 22:50:21 server id 181  end_log_pos 988 CRC32 0x347ed8f5 Query thread_id=3 exec_time=0 error_cod

e=0

SET TIMESTAMP=1508165421/*!*/;

BEGIN

/*!*/;

# at 988

#171016 22:50:21 server id 181  end_log_pos 1037 CRC32 0x8ebe7b63 Table_map: `bhs`.`test` mapped to number 219

# at 1037

#171016 22:50:21 server id 181  end_log_pos 1079 CRC32 0x132c2b82 Write_rows: table id 219 flags: STMT_END_F

### INSERT INTO `bhs`.`test`

### SET

###   @1=3 /* INT meta=0 nullable=1 is_null=0 */

###   @2='d' /* VARSTRING(22) meta=22 nullable=1 is_null=0 */

# at 1079

#171016 22:50:21 server id 181  end_log_pos 1110 CRC32 0xc676ebaa Xid = 12

COMMIT/*!*/;

# at 1110

#171016 22:52:10 server id 181  end_log_pos 1175 CRC32 0x2c454196 Anonymous_GTID last_committed=4 sequence_

number=5

SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;

# at 1175

#171016 22:52:10 server id 181  end_log_pos 1246 CRC32 0xd494ad64 Query thread_id=5 exec_time=0 error_cod

e=0

SET TIMESTAMP=1508165530/*!*/;

BEGIN

/*!*/;

# at 1246

#171016 22:52:10 server id 181  end_log_pos 1295 CRC32 0x3bddb222 Table_map: `bhs`.`test` mapped to number 219

# at 1295

#171016 22:52:10 server id 181  end_log_pos 1351 CRC32 0x26842168 Delete_rows: table id 219 flags: STMT_END_F

### DELETE FROM `bhs`.`test`

5、开始恢复删除数据及表，挖掘binlog日志找到创建表的位置及delete删除前的位置，通过mysqlbinlog命令在数据库内重放

mysqlbinlog --start-position=219 --stop-position=1246 /mysql/data/binlog.000001 |mysql -uroot -p bhs

6、查看验证：数据已成功恢复

mysql> use bhs;

Database changed

mysql> show tables;

+---------------+

| Tables_in_bhs |

+---------------+

| test          |

+---------------+

1 row in set (0.00 sec)

mysql> 

mysql> select * from test;

+------+------+

| id   | name |

+------+------+

|    1 | a    |

|    2 | c    |

|    3 | d    |

+------+------+

3 rows in set (0.00 sec)

时间： 2024-09-29 09:34:10

Mysql通过mysqlbinlog工具恢复误删除数据的相关文章

利用Mysqlbinlog工具恢复MySQL数据库的例子

MYSQL启用日志 [root@jianshe99]# whereis my.ini [root@jianshe99]# vi /etc/my.cnf [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the

MYSQL启用日志，查看日志，利用Mysqlbinlog工具恢复MySQL数据库

MYSQL启用日志 [root@jianshe99]# whereis my.ini [root@jianshe99]# vi /etc/my.cnf [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the

如何通过非RMAN方式恢复误删除数据文件和控制文件

在Unix/Linux上删除所有的Controlfile控制文件后实例并不会在第一时间crash,相反居然还可以顺利完成FULL checkpoint . 这是为什么呢?  ---注意这个问题仅适用于Unix/Linux, 在Windows平台上不允许删除 已经被其他进程打开的文件. 究其根本原因是在Linux/Unix上Read 或 Write一个文件,进程都会打开一个与此文件相关联的 打开文件描述符 Open File Descriptors (a file descriptor (FD)

MYSQL教程:使用备份恢复数据

恢复过程包括两个信息源---备份文件和二进制日志,备份文件可使用数据恢复到执行备份时的状态,而二进制日志可恢复到发生故障时的状态.下面分别介绍如何利用这两个文件恢复一个数据库或恢复单个数据表. 恢复整个数据库的步骤: 把需恢复的数据库的整个目录的内容拷贝到其它地方,以备用. 使用最近的备份文件重载数据库.如果使用mysqldump生成的备份,则可使用它们作为mysql的输入重载:如果是通过拷贝数据库目录来备份的,则要关闭数据库服务器,再把备份重新拷贝到数据目录,再重启数据库服务器. 通过二进制日

SQL Server 2008 数据库误删除数据的恢复

原文:SQL Server 2008 数据库误删除数据的恢复 原文:http://www.cnblogs.com/dudu/archive/2011/10/15/sql_server_recover_deleted_records.html SQL Server中误删除数据的恢复本来不是件难事,从事务日志恢复即可.但是,这个恢复需要有两个前提条件: 1. 至少有一个误删除之前的数据库完全备份. 2. 数据库的恢复模式(Recovery mode)是"完整(Full)". 针对这两个前提

SQL Server2008 数据库误删除数据的恢复方法分享_mssql2008

SQL Server中误删除数据的恢复本来不是件难事,从事务日志恢复即可.但是,这个恢复需要有两个前提条件: 1. 至少有一个误删除之前的数据库完全备份. 2. 数据库的恢复模式(Recovery mode)是"完全(Full)". 针对这两个前提条件,会有三种情况: 情况一.如果这两个前提条件都存在,通过SQL语句只需三步就能恢复(参考文章),无法借助第三方工具. a) 备份当前数据库的事务日志:BACKUP LOG [数据库名] TO disk= N'备份文件名' WITH NOR

通过sqlserver日志恢复误删除的数据

原文:通过sqlserver日志恢复误删除的数据       如果你已经急的焦头烂额,看到这篇文章的时候,请你换个坐姿,深呼吸几次,静下心来将这篇文章读完,也许你的问题迎刃而解.     我遇到的情况是这样的,网站被植入木马,盗取了我的web.config文件,web.config文件里面的数据库连接字符串没有加密,而我的数据库远程连接又没有做IP限制,黑客通过数据库客户端连上我的数据库后,将所有的表都Delete掉了,所以大家一定要有一个好习惯将数据库连接字符串加密或者对远程访问数据库的IP作

通过frm&ibd 恢复 Mysql ibdata 丢失或损坏的数据教程

        有时候mysql没有做好数据备份,或者被数据管理员误删,或者ibdata损坏了我们如何恢复呢?别怕,只要有部分frm.ibd存在,下面就是恢复教程. mysql存储在磁盘中,各种天灾人祸都会导致数据丢失.大公司的时候我们常常需要做好数据冷热备,对于小公司来说要做好所有数据备份需要支出大量的成本,很多公司也是不现实的.万一还没有做好备份,数据被误删除了,或者ibdata损坏了怎么办呢?别担心,只要有部分的frm.ibd存在就可以恢复部分数据. 注意: 一.这个是对innodb的数据

oracel数据库Solaris rm datafile recovery—利用句柄误删除数据文件恢复

今天早上接到有客户恢复请求,他一不小心在solaris系统中使用rm -rf oradata命令把一个分区下面的所有数据文件全部删除了.现在不知道怎么办,请求我们给予支持.上去检查发现比较幸运,数据库没有crash,看来直接考虑使用句柄进行恢复 root@CNISORCLSVR # uname -a SunOS CNISORCLSVR 5.9 Generic_112233-08 sun4u sparc SUNW,Sun-Fire-880 root@CNISORCLSVR # ps -ef|gre