(一)概述
在日常MySQL数据库运维过程中,可能会遇到用户误删除数据,常见的误删除数据操作有:
这些情况虽然不会经常遇到,但是遇到了,我们需要有能力将其恢复,下面讲述如何恢复。
(二)恢复原理
如果要将数据库恢复到故障点之前,那么需要有数据库全备和全备之后产生的所有二进制日志。
全备作用 :使用全备将数据库恢复到上一次完整备份的位置;
二进制日志作用:利用全备的备份集将数据库恢复到上一次完整备份的位置之后,需要对上一次全备之后数据库产生的所有动作进行重做,而重做的过程就是解析二进制日志文件为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 | +----------+ row in set (0.14 sec) mysql> select count(*) from test02; +----------+ | count(*) | +----------+ | 930000 | +----------+ 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 | +----------+ row in set (0.12 sec) mysql> select count(*) from test02; +----------+ | count(*) | +----------+ | 753238 | +----------+ 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 | +----------+ row in set (0.15 sec) mysql> select count(*) from test02; +----------+ | count(*) | +----------+ | 930000 | +----------+ row in set (0.13 sec)
(四)总结
1.对于DML操作,binlog记录了所有的DML数据变化:
--对于insert,binlog记录了insert的行数据
--对于update,binlog记录了改变前的行数据和改变后的行数据
--对于delete,binlog记录了删除前的数据
假如用户不小心误执行了DML操作,可以使用mysqlbinlog将数据库恢复到故障点之前。
2.对于DDL操作,binlog只记录用户行为,而不记录行变化,但是并不影响我们将数据库恢复到故障点之前。
总之,使用mysqldump全备加binlog日志,可以将数据恢复到故障前的任意时刻。
到此这篇关于MySQL使用mysqldump+binlog完整恢复被删除的数据库的文章就介绍到这了,更多相关MySQL恢复被删除的数据库内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库!
本文向大家介绍浅谈mysqldump使用方法(MySQL数据库的备份与恢复),包括了浅谈mysqldump使用方法(MySQL数据库的备份与恢复)的使用技巧和注意事项,需要的朋友参考一下 #mysqldump --help 1.mysqldump的几种常用方法: (1)导出整个数据库(包括数据库中的数据) mysqldump -u username -p dbname > dbname.sql
本文向大家介绍复制MySQL数据库而不使用mysqldump?,包括了复制MySQL数据库而不使用mysqldump?的使用技巧和注意事项,需要的朋友参考一下 要复制MySQL数据库,语法如下- 让我们首先创建一个表- 使用插入命令在表中插入一些记录- 使用select语句显示表中的所有记录- 这将产生以下输出- 这是复制MySQL数据库的查询- 使用select语句显示新表中的所有记录- 这将产
本文向大家介绍MySQL数据库使用mysqldump导出数据详解,包括了MySQL数据库使用mysqldump导出数据详解的使用技巧和注意事项,需要的朋友参考一下 mysqldump是mysql用于转存储数据库的客户端程序。它主要产生一系列的SQL语句,可以封装到文件,该文件包含有所有重建您的数据库所需要的 SQL命令如CREATE DATABASE,CREATE TABLE,INSERT等等。可
数据库恢复是指以备份为基础,与备份相对应的系统维护和管理操作。 系统进行恢复操作时,先执行一些系统安全性的检查,包括检查所要恢复的数据库是否存在、数据库是否变化及数据库文件是否兼容等,然后根据所采用的数据库备份类型采取相应的恢复措施。 数据库恢复机制设计的两个关键问题是:第一,如何建立冗余数据;第二,如何利用这些冗余数据实施数据库恢复。 建立冗余数据最常用的技术是数据转储和登录日志文件。通常在一个
当数据丢失或意外损坏时,可以通过恢复已经备份的数据来尽量减少数据的丢失和破坏造成的损失。本节主要介绍如何对备份的数据进行恢复操作。 在《 MySQL mysqldump备份数据库》一节中介绍了如何使用 mysqldump 命令将数据库中的数据备份成一个文本文件,且备份文件中通常包含 CREATE 语句和 INSERT 语句。 在 MySQL 中,可以使用 mysql 命令来恢复备份的数据。mysq
问题内容: 我已经使用名为library的数据库的mysqldump实用程序创建了一个名为ab.sql的文件。工作正常。现在,我正在尝试使用mysqlimport还原它。我的数据库已经存在。但我想重写它。我正在使用命令 在命令行中,但显示错误消息, mysqlimport:错误:1146,使用表:ab时,表’library.ab’不存在 迫切需要帮助。 问题答案: mysqlimport将文本文件