(一)概述

在日常MySQL数据库运维过程中,可能会遇到用户误删除数据,常见的误删除数据操作有:

  • 用户执行delete,因为条件不对,删除了不应该删除的数据(DML操作);
  • 用户执行update,因为条件不对,更新数据出错(DML操作);
  • 用户误删除表drop table(DDL操作);
  • 用户误清空表truncate(DDL操作);
  • 用户删除数据库drop database,跑路(DDL操作)
  • …等

这些情况虽然不会经常遇到,但是遇到了,我们需要有能力将其恢复,下面讲述如何恢复。

(二)恢复原理

如果要将数据库恢复到故障点之前,那么需要有数据库全备和全备之后产生的所有二进制日志。

全备作用         :使用全备将数据库恢复到上一次完整备份的位置;

二进制日志作用:利用全备的备份集将数据库恢复到上一次完整备份的位置之后,需要对上一次全备之后数据库产生的所有动作进行重做,而重做的过程就是解析二进制日志文件为SQL语句,然后放到数据库里面再次执行。

举个例子:小明在4月1日晚上8:00使用了mysqldump对数据库进行了备份,在4月2日早上12:00的时候,小华不小心删除了数据库,那么,在执行数据库恢复的时候,需要使用4月1日晚上的完整备份将数据库恢复到“4月1日晚上8:00”,那4月1日晚上8:00以后到4月2日早上12:00之前的数据如何恢复呢?就得通过解析二进制日志来对这段时间执行过的SQL进行重做。

(三)删库恢复测试

(3.1)实验目的

在本次实验中,我直接测试删库,执行drop database lijiamandb,确认是否可以恢复。

(3.2)测试过程

在测试数据库lijiamandb中创建测试表test01和test02,然后执行mysqldump对数据库进行全备,之后执行drop database,确认database是否可以恢复。

STEP1:创建测试数据,为了模拟日常繁忙的生产环境,频繁的操作数据库产生大量二进制日志,我特地使用存储过程和EVENT产生大量数据。

创建测试表:

use lijiamandb;

create table test01
(
id1 int not null auto_increment,
name varchar(30),
primary key(id1)
); create table test02
(
id2 int not null auto_increment,
name varchar(30),
primary key(id2)
);

创建存储过程,往测试表里面插入数据,每次执行该存储过程,往test01和test02各自插入10000条数据:

CREATE DEFINER=`root`@`%` PROCEDURE `p_insert`()
BEGIN
#Routine body goes here...
DECLARE str1 varchar(30);
DECLARE str2 varchar(30);
DECLARE i int;
set i = 0; while i < 10000 do
set str1 = substring(md5(rand()),1,25);
insert into test01(name) values(str1);
set str2 = substring(md5(rand()),1,25);
insert into test02(name) values(str1);
set i = i + 1;
end while;
END

制定事件,每隔10秒钟,执行上面的存储过程:

use lijiamandb;
create event if not exists e_insert
on schedule every 10 second
on completion preserve
do call p_insert();

启动EVENT,每个10s自动向test01和test02各自插入10000条数据

mysql> show variables like '%event_scheduler%';
+----------------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------------+-------+
| event_scheduler | OFF |
+----------------------------------------------------------+-------+ mysql> set global event_scheduler = on;
Query OK, 0 rows affected (0.08 sec)

--过3分钟。。。

STEP2:第一步生成大量测试数据后,使用mysqldump对lijiamandb数据库执行完全备份

mysqldump -h192.168.10.11 -uroot -p123456 -P3306 --single-transaction --master-data=2 --events --routines --databases lijiamandb > /mysql/backup/lijiamandb.sql

注意:必须要添加--master-data=2,这样才会备份集里面mysqldump备份的终点位置。

--过3分钟。。。

STEP3:为了便于数据库删除前与删除后数据一致性校验,先停止表的数据插入,此时test01和test02都有930000行数据,我们后续恢复也要保证有930000行数据。

mysql> set global event_scheduler = off;
Query OK, 0 rows affected (0.00 sec) mysql> select count(*) from test01;
+----------+
| count(*) |
+----------+
| 930000 |
+----------+
1 row in set (0.14 sec) mysql> select count(*) from test02;
+----------+
| count(*) |
+----------+
| 930000 |
+----------+
1 row in set (0.13 sec)

STEP4:删除数据库

mysql> drop database lijiamandb;
Query OK, 2 rows affected (0.07 sec)

STEP5:使用mysqldump的全备导入

mysql> create database lijiamandb;
Query OK, 1 row affected (0.01 sec) mysql> exit
Bye
[root@masterdb binlog]# mysql -uroot -p123456 lijiamandb < /mysql/backup/lijiamandb.sql
mysql: [Warning] Using a password on the command line interface can be insecure.

在执行全量备份恢复之后,发现只有753238笔数据:

[root@masterdb binlog]# mysql -uroot -p123456 lijiamandb 

mysql> select count(*) from test01;
+----------+
| count(*) |
+----------+
| 753238 |
+----------+
1 row in set (0.12 sec) mysql> select count(*) from test02;
+----------+
| count(*) |
+----------+
| 753238 |
+----------+
1 row in set (0.11 sec)

很明显,全量导入之后,数据不完整,接下来使用mysqlbinlog对二进制日志执行增量恢复。

使用mysqlbinlog进行增量日志恢复最重要的就是确定待恢复的起始位置(start-position)和终止位置(stop-position),起始位置(start-position)是我们执行全被之后的位置,而终止位置则是故障发生之前的位置。

STEP6:确认mysqldump备份到的最终位置

[root@masterdb backup]# cat lijiamandb.sql |grep "CHANGE MASTER"
-- CHANGE MASTER TO MASTER_LOG_FILE='master-bin.000044', MASTER_LOG_POS=8526828

备份到了44号日志的8526828位置,那么恢复的起点可以设置为:44号日志的8526828。

--接下来确认要恢复的终点位置,即执行"DROP DATABASE LIJIAMAN"之前的位置,需要到binlog里面确认。

[root@masterdb binlog]# ls
master-bin.000001 master-bin.000010 master-bin.000019 master-bin.000028 master-bin.000037 master-bin.000046 master-bin.000055
master-bin.000002 master-bin.000011 master-bin.000020 master-bin.000029 master-bin.000038 master-bin.000047 master-bin.000056
master-bin.000003 master-bin.000012 master-bin.000021 master-bin.000030 master-bin.000039 master-bin.000048 master-bin.000057
master-bin.000004 master-bin.000013 master-bin.000022 master-bin.000031 master-bin.000040 master-bin.000049 master-bin.000058
master-bin.000005 master-bin.000014 master-bin.000023 master-bin.000032 master-bin.000041 master-bin.000050 master-bin.000059
master-bin.000006 master-bin.000015 master-bin.000024 master-bin.000033 master-bin.000042 master-bin.000051 master-bin.index
master-bin.000007 master-bin.000016 master-bin.000025 master-bin.000034 master-bin.000043 master-bin.000052
master-bin.000008 master-bin.000017 master-bin.000026 master-bin.000035 master-bin.000044 master-bin.000053
master-bin.000009 master-bin.000018 master-bin.000027 master-bin.000036 master-bin.000045 master-bin.000054 # 多次查找,发现drop database在54号日志文件
[root@masterdb binlog]# mysqlbinlog -v master-bin.000056 | grep -i "drop database lijiamandb"
[root@masterdb binlog]# mysqlbinlog -v master-bin.000055 | grep -i "drop database lijiamandb"
[root@masterdb binlog]# mysqlbinlog -v master-bin.000055 | grep -i "drop database lijiamandb"
[root@masterdb binlog]# mysqlbinlog -v master-bin.000054 | grep -i "drop database lijiamandb"
drop database lijiamandb

# 保存到文本,便于搜索
[root@masterdb binlog]# mysqlbinlog -v master-bin.000054 > master-bin.txt # 确认drop database之前的位置为:54号文件的9019487
# at 9019422
#200423 16:07:46 server id 11 end_log_pos 9019487 CRC32 0x86f13148 Anonymous_GTID last_committed=30266 sequence_number=30267 rbr_only=no
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 9019487
#200423 16:07:46 server id 11 end_log_pos 9019597 CRC32 0xbd6ea5dd Query thread_id=100 exec_time=0 error_code=0
SET TIMESTAMP=1587629266/*!*/;
SET @@session.sql_auto_is_null=0/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
drop database lijiamandb
/*!*/;
# at 9019597
#200423 16:09:25 server id 11 end_log_pos 9019662 CRC32 0x8f7b11dc Anonymous_GTID last_committed=30267 sequence_number=30268 rbr_only=no
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 9019662
#200423 16:09:25 server id 11 end_log_pos 9019774 CRC32 0x9b42423d Query thread_id=100 exec_time=0 error_code=0
SET TIMESTAMP=1587629365/*!*/;
create database lijiamandb

STEP7:确定了开始结束点,执行增量恢复

开始:44号日志的8526828

结束:54号文件的9019487

这里分为3条命令执行,起始日志文件涉及到参数start-position参数,单独执行;中止文件涉及到stop-position参数,单独执行;中间的日志文件不涉及到特殊参数,全部一起执行。

# 起始日志文件

mysqlbinlog --start-position=8526828  /mysql/binlog/master-bin.000044 | mysql -uroot -p123456
 

# 中间日志文件

mysqlbinlog /mysql/binlog/master-bin.000045 /mysql/binlog/master-bin.000046 /mysql/binlog/master-bin.000047 /mysql/binlog/master-bin.000048 /mysql/binlog/master-bin.000049 /mysql/binlog/master-bin.000050 /mysql/binlog/master-bin.000051 /mysql/binlog/master-bin.000052 /mysql/binlog/master-bin.000053 | mysql -uroot -p123456
 

# 终止日志文件

mysqlbinlog --stop-position=9019487 /mysql/binlog/master-bin.000054 | mysql -uroot -p123456

STEP8:恢复结束,确认全部数据已经还原

[root@masterdb binlog]# mysql -uroot -p123456 lijiamandb
mysql> select count(*) from test01;
+----------+
| count(*) |
+----------+
| 930000 |
+----------+
1 row in set (0.15 sec) mysql> select count(*) from test02;
+----------+
| count(*) |
+----------+
| 930000 |
+----------+
1 row in set (0.13 sec)

(四)总结                                                                        

1.对于DML操作,binlog记录了所有的DML数据变化:                                                                   
     --对于insert,binlog记录了insert的行数据                                                                   
     --对于update,binlog记录了改变前的行数据和改变后的行数据                                                                   
     --对于delete,binlog记录了删除前的数据                                                                   

假如用户不小心误执行了DML操作,可以使用mysqlbinlog将数据库恢复到故障点之前。                        
                                                                                                   
   2.对于DDL操作,binlog只记录用户行为,而不记录行变化,但是并不影响我们将数据库恢复到故障点之前。
                                                                                                   
  总之,使用mysqldump全备加binlog日志,可以将数据恢复到故障前的任意时刻。 

相关文档集合:

1.MySQL日志--二进制日志(binlog)                  
2.使用mysqlbinlog查看二进制日志                  
3.MySQL使用mysqldump+binlog完整恢复被删除的数据库
4.使用binlog2sql工具来恢复数据库                 
5.MySQL闪回工具—MyFlash

MySQL使用mysqldump+binlog完整恢复被删除的数据库的更多相关文章

  1. Linux 上通过binlog文件 恢复mysql 数据库详细步骤

    一.binlog 介绍 服务器的二进制日志记录着该数据库的所有增删改的操作日志(前提是要在自己的服务器上开启binlog),还包括了这些操作的执行时间.为了显示这些二进制内容,我们可以使用mysqlb ...

  2. 快速从mysqldump文件中恢复一个表

    快速从较大的mysqldump文件中恢复一个表到数据库中: 1.先获取目标表(md_gas_check_record)在文件中的位置 [publish@LF-PRO-DB-01 ~]$ cat dby ...

  3. 解说mysql之binlog日志以及利用binlog日志恢复数据

    众所周知,binlog日志对于mysql数据库来说是十分重要的.在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷! 废 ...

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

    众所周知,binlog日志对于mysql数据库来说是十分重要的.在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷! 一 ...

  5. MySQL的binlog日志恢复(转)

    binlog 基本认识 MySQL的二进制日志可以说是MySQL最重要的日志了,它记录了所有的DDL和DML(除了数据查询语句)语句,以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日 ...

  6. 【转】Mysql之binlog日志说明及利用binlog日志恢复数据操作记录

    众所周知,binlog日志对于mysql数据库来说是十分重要的.在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷! 废 ...

  7. 使用Binlog日志恢复误删的MySQL数据

    解到: MySQL的binlog日志是什么?通常是用来干什么的? 模拟一次误删数据的操作,并且使用binlog日志恢复误删的数据. 写这篇文章的初衷,是有一次我真的险些把测试数据库的一张表给删除了,当 ...

  8. MySQL二进制binlog日志说明以及利用binlog日志恢复数据

    MySQL的binlog日志对于mysql数据库来说是十分重要的.在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全量备份+binlog日志恢复增量数据部分). 一.关于 ...

  9. mysql之 mysqldump 备份恢复详解

    mysqldump是MySQL用于转存储数据库的客户端程序.转储包含创建表和/或装载表的SQL语句 ,用来实现轻量级的快速迁移或恢复数据库,是mysql数据库实现逻辑备份的一种方式. mysqldum ...

随机推荐

  1. Hive学习笔记六

    目录 查询 一.基本查询 1.全表和特定列查询 2.列别名 3.算术运算符 4.常用函数 5.Limit语句 二.Where语句 1.比较运算符(Between/In/ Is Null) 2.Like ...

  2. 对于一个由0..n的所有数按升序组成的序列,我们要进行一些筛选,每次我们取当前所有数字中从小到大的第奇数位个的数,并将其丢弃。重复这一过程直到最后剩下一个数。请求出最后剩下的数字。

    输入描述: 每组数据一行一个数字,为题目中的n(n小于等于1000). 输出描述: 一行输出最后剩下的数字.我的思路是用两个链表,一个用于存储原数据,一个用于存储要丢掉的数据,再循环从元数据中剔除掉即 ...

  3. ElasticSearch 9200 9300 端口

    9300端口: ES节点之间通讯使用 9200端口: ES节点 和 外部 通讯使用 9300是TCP协议端口号,ES集群之间通讯端口号 9200端口号,暴露ES RESTful接口端口号

  4. iOS 页面流畅技巧(1)

    一.屏幕显示图像原理 首先明确两个概念:水平同步信号.垂直同步信号. CRT 的电子枪按照上图中的方式,从上到下一行一行的扫描,扫描完成后显示器就呈现一帧画面,随后电子枪回到初始位置继续下一次的扫描. ...

  5. 1.Metasploit介绍与基本命令

    Metasploit体系框架介绍 Metasploit是目前世界上领先的渗透测试工具,也是信息安全与渗透测试领域最大的开源项目之一.它彻底改变了我们执行安全测试的方式. Metasploit之所以流行 ...

  6. 基于Asp.Net Core,利用ZXing来生成二维码的一般流程

    本文主要介绍如何在.net环境下,基于Asp.Net Core,利用ZXing来生成二维码的一般操作.对二维码工作原理了解,详情见:https://blog.csdn.net/weixin_36191 ...

  7. B - Bound Found POJ - 2566(尺取 + 对区间和的绝对值

    B - Bound Found POJ - 2566 Signals of most probably extra-terrestrial origin have been received and ...

  8. 面试官:JavaScript 原始数据类型 Symbol 有什么用?

    以前提到 JavaScript 原始数据类型时,我们知道有Number,String,Null,Boolean,Undefined这几种.ES6 引入了新的基本数据类型Symbol和BigInt.今天 ...

  9. MySQL(Linux)编码问题——网站刚刚上线就被光速打脸

    MySQL(Linux)编码问题--刚刚上线就被光速打脸 MySql默认编码问题 总结了一下,大致是这样的 修改数据库配置 在URL上加载参数 MySql默认编码问题 说到这里真的想哭,改了无数bug ...

  10. Android Studio使用butterknife库绑定控件ID注解

    在线导入butterknife的jar包 在Android-app-Open Module Settings下选中module下的app 选择Dependencies,点击右边的“+”,选择第一个:1 ...