mysql利用mysqlbinlog命令恢复误删除数据

实验环境:

MYSQL 5.7.22

开启二进志日志

日志格式MIXED

实验过程:

1、执行:FLUSH LOGS;

master-bin.000014 文件就是新生成的文件

刷新日志是为了实验内容更直观,更容易观察到整个实验过程的内容。

我看到网上许多文章有在用REST MASTER;而未说明此命令的严重性

这条命令会删除所有日志文件,并将文件名和记录点进行重置归零,99%的情况下是用不到这条命令的

删除日志可以用PURGE MASTER LOGS...这样保险一点

2、新日志文件已经生成,先观察一下内容,有几个点需要了解

查看二进日日志文件命令:mysqlbinlog master-bin.000014

# at 4
#180903 16:19:12 server id 1  end_log_pos 123 CRC32 0xe03659b3  Start: binlog v 4, server v 5.7.22-log created 180903 16:19:12

先看上边两个箭头:

# at 4(事件开始点)

#180903 16:19:12 (代表的是时间)

server id 1(主备复制时需要为每个MYSQL数据库指定唯一的SERVER ID,我的未配置,默认是1)

end_log_pos 123(事件结束点)

再看下边两个箭头:

# at 123(事件开始点,和上边的事件结束点是对应的)

end_log_pos 154(事件结束点)

at 4 和 at 123之间的内容就是事件内容

3、模拟业务场景,建表,插入数据,最后将某个表删除;为了真实,我建了两个库,同时向不同的库写入内容,最后将其中一个库中的某个表删除。

mysql> FLUSH LOGS;
Query OK, 0 rows affected (0.01 sec)

mysql> create database t1;
Query OK, 1 row affected (0.03 sec)

mysql> create database t2;
Query OK, 1 row affected (0.00 sec)

mysql> use t1;
Database changed
mysql> create table t1 (id int);
Query OK, 0 rows affected (0.03 sec)

mysql> use t2;
Database changed
mysql> create table t2 (id int);
Query OK, 0 rows affected (0.03 sec)

mysql> insert into t2 values (3);
Query OK, 1 row affected (0.01 sec)

mysql> insert into t2 values (4);
Query OK, 1 row affected (0.01 sec)

mysql> use t1;
Database changed
mysql> insert into t1 values (1);
Query OK, 1 row affected (0.01 sec)

mysql> insert into t1 values (2);
Query OK, 1 row affected (0.01 sec)

mysql> use t2;
Database changed
mysql> insert into t2 values(20);
Query OK, 1 row affected (0.01 sec)

mysql> use t1;
Database changed
mysql> insert into t1 values(10);
Query OK, 1 row affected (0.01 sec)

mysql> drop table t1;
Query OK, 0 rows affected (0.02 sec)

mysql> use t2;
Database changed
mysql> insert into t2 values(222);
Query OK, 1 row affected (0.01 sec)

mysql>

建立T1、T2库,建立T1、T2表。

向T1插入数据:1、2、10

向T2插入数据:3、4、20、222

模拟场景,删除T1表,T2库T2表业务还在继续运行

现在将要通过日志将T1表进行恢复。

首先要先找到那个删除命令的日志点:

mysqlbinlog master-bin.000014|grep -5a "DROP TABLE"

看到#AT 2439 (记下这个数字)

在这个事件点执行的DROP TABLE操作。

由于日志文件内不只有T1库的日志,还有T2库的日志,一会只取T1数据库的日志

而且还只取2439日志点之前的日志,再进行重新应用

如果把2439的日志取的话,再应用时数据库会重新建库建表,插数据, 还会执行这条删表语句。

mysqlbinlog -d t1 --stop-position=2439  master-bin.000014>test.sql(执行这条语句竟然报错了)

WARNING: The option --database has been used. It may filter parts of transactions, but will include the GTIDs in any case. If you want to exclude or include transactions, you should use the options --exclude-gtids or --include-gtids, respectively, instead.
暂时弄不清楚原因,百度了下修改成:

mysqlbinlog master-bin.000014 -d t1  --skip-gtids --stop-position=2439>test.sql

-d:参数是指定某个数据库日志

命令意思是将master-bin.000014日志文件内的T1数据库日志,事件点2439之前的日志,输出到test.sql

# tail test.sql

看看文件最后几行

登录数据库:

mysql> use t1;
Database changed

mysql> source test.sql

中间报错了一次,因为里边包含建库T1语句。

再查看表内容

这样数据就回来了。
————————————————
版权声明:本文为CSDN博主「柴米油盐酱醋0」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/chaigang/article/details/82350399

原文地址:https://www.cnblogs.com/yaoyangding/p/12237352.html

时间: 2024-10-10 01:37:36

mysql利用mysqlbinlog命令恢复误删除数据的相关文章

如何通过Mysql的二进制日志恢复数据库数据

经常有网站管理员因为各种原因和操作,导致网站数据误删,而且又没有做网站备份,结果不知所措,甚至给网站运营和盈利带来负面影响.所以本文我们将和大家一起分享学习下如何通过Mysql的二机制日志(binlog)来恢复数据. 系统环境: 操作系统:CentOS 6.5 X64  (虚拟机): WEB服务:PHP+Mysql+apache: 网站:为方便,直接在本地用蝉知系统搭建一个DEMO站点: 操作步骤: 1.开启binlog功能及基本操作: 2.往站点添加数据: 3.刷新binlog日志: 4.删除

MySQL利用binlog来恢复数据库

1.根据binlog解析出所有ring数据库的所有sql [[email protected] ]$ mysqlbinlog --no-defaults --database=ring --start-datetime="2005-04-20 9:55:00" --stop-datetim="2009-04-08 08:05:00" /u01/mysql/log/mysql-bin.000005 > /u01/mysql/log/mysql_restore5.

Mysql: 利用强制索引去掉重数据

数据库版本: [[email protected]mysqltest ~]# mysql -u root -p123456 Welcome to the MySQL monitor.  Commands end with ; or \g. Your MySQL connection id is 389805 Server version: 5.1.73-community MySQL Community Server (GPL) Copyright (c) 2000, 2013, Oracle

mysql利用bin-log恢复误删除数据.

模拟备份数据库mysqldump db1 > db1.sql 启用新的bin-log文件mysql>flush logs; mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

mysql"闪回"技术恢复误删除误更改的数据

相信很多人都遇到过忘带where条件或者where条件漏写了一个和写错了的情况,结果执行了delete/update后把整张表的数据都给改了.传统的解决方法是:利用最近的全量备份+增量binlog备份,恢复到误操作之前的状态,但是此方法有一个弊端,那就是随着表的记录增大,binlog的增多,恢复起来会很费时费力. 现在有一个简单的方法,可以恢复到误操作之前的状态.听起来这方法似乎利用的是Oracle的闪回功能,但MySQL目前(包括最新的V5.7版本与MariaDB10.1分支版本)还不具有这样

Mysql利用存储过程插入400W条数据

CREATE TABLE dept( /*部门表*/ deptno MEDIUMINT UNSIGNED NOT NULL DEFAULT 0, /*编号*/ dname VARCHAR(20) NOT NULL DEFAULT "",/*名称*/ loc VARCHAR(13) NOT NULL DEFAULT "" /*地点*/ )ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE emp( /*EMP雇员表*/ e

mysqlbinlog结合sed命令恢复update时未加where条件之前的数据

一.环境说明 腾讯云机器上自建MySQL 上update操作时,忘加where条件 ,使用mysqlbinlog搭配sed命令完美还原MySQL版本号:5.6.39:mysql必须开启binlog,并且mysql的binlog最好是Row模式;mysql数据库指定字符集位utf8,同时表的字符集也得为utf8,否则在mysqlbinlog 解析出来的sql文件对于中文汉字的会出现乱码,导致最后恢复数据到线上的表中报错.满足以上条件这样可以极大的保证数据恢复的几率.当然把控好数据库的权限问题,禁止

利用extundelete工具恢复Centos6.5中误删除的文件

实验目的:利用extundelete工具恢复误删除的文件实验环境:在Linux系统中安装一台Centos6.5在Centos6.5中新增磁盘并创建分区,模拟删除并进行回复的操作设置文件共享权限,使虚拟机可使用宿主机上的文件(需要使用宿主机上的安装包)yum仓库提前安装完成,可直接使用实验安装包:e2fsprogs-libs-1.41.12-18.e16.x86_64.rpmlibcom err-devel-1.41.12-18.el6.x86_64.rpme2fsprogs-devel-1.41

Mysql之binlog日志说明及利用binlog日志恢复数据操作记录

众所周知,binlog日志对于mysql数据库来说是十分重要的.在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷! 废话不多说,下面是梳理的binlog日志操作解说: 一.初步了解binlogMySQL的二进制日志binlog可以说是MySQL最重要的日志,它记录了所有的DDL和DML语句(除了数据查询语句select),以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的. DDL-