MySQL数据库增量数据恢复案例
浏览量:947
一、场景概述
MySQL数据库每日零点自动全备
某天上午10点,小张莫名其妙地drop了一个数据库
我们需要通过全备的数据文件,以及增量的binlog文件进行数据恢复
二、主要思想
利用全备的sql文件中记录的CHANGE MASTER语句,binlog文件及其位置点信息,找出binlog文件增量的部分
用mysqlbinlog命令将上述的binlog文件导出为sql文件,并剔除其中的drop语句
通过全备文件和增量binlog文件的导出sql文件,就可以恢复到完整的数据
三、过程示意图

四、操作过程
1、模拟数据
#创建库、表并插入数据 create database student; use student; CREATE TABLE `person` ( `number` int(11) DEFAULT NULL, `name` varchar(255) DEFAULT NULL, `birthday` date DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8; insert into person values(1,'zy','1995-12-26'); insert into person values(2,'youngcheung','1995-04-24'); #查看数据 mysql> use student; Database changed mysql> select * from person; +--------+-------------+------------+ | number | name | birthday | +--------+-------------+------------+ | 1 | zy | 1995-12-26 | | 2 | youngcheung | 1995-04-24 | +--------+-------------+------------+ 2 rows in set (0.00 sec)
2.全量备份
mysqldump -uroot -pxxxxxx -B -F -R -x --master-data=2 student|gzip>backup.sql.gz
参数说明:
-B指定数据库
-F刷新日志
-R备份存储过程等
-x锁表
--master-data在备份语句里添加CHANGEMASTER语句以及binlog文件及位置点信息
3、继续插入数据
#插入数据 mysql> use student; Database changed mysql> insert into person values(3,'test1','1111111'); Query OK, 1 row affected, 1 warning (0.00 sec) mysql> insert into person values(4,'test2','1111112'); Query OK, 1 row affected, 1 warning (0.00 sec) #查看数据 mysql> select * from person; +--------+-------------+------------+ | number | name | birthday | +--------+-------------+------------+ | 1 | zy | 1995-12-26 | | 2 | youngcheung | 1995-04-24 | | 3 | test1 | 2011-11-11 | | 4 | test2 | 2011-11-11 | +--------+-------------+------------+ 4 rows in set (0.00 sec) 注意⚠️:此时误操作删除student表 mysql>drop database student;
4、查看全备之后新增的binlog文件
[root@YoungCheung ~]# [root@YoungCheung ~]# ll -rw-r--r-- 1 root root 890 Apr 14 18:19 backup.sql.gz [root@YoungCheung ~]# gzip -d backup.sql.gz [root@YoungCheung ~]# ll -rw-r--r-- 1 root root 2264 Apr 14 18:19 backup.sql [root@YoungCheung ~]# grep CHANGE backup.sql -- CHANGE MASTER TO MASTER_LOG_FILE='mysqlbin-log.000004', MASTER_LOG_POS=120;
这是全备时刻的binlog文件位置,即mysql-bin.000004的120行,因此在该文件之前的binlog文件中的数据都已经包含在这个全备的sql文件中了
5、移动binlog文件,并读取sql,剔除其中的drop语句
[root@YoungCheung ~]# cp /usr/local/mysql/mysqlbin-log.000004 . [root@YoungCheung ~]# mysqlbinlog -d student mysqlbin-log.000004 >004.sql 注意⚠️:用vim编辑004.sql文件,剔除drop语句
在恢复全备数据之前必须将该binlog文件移出,否则恢复过程中,会继续写入语句到binlog,最终导致增量恢复数据部分变得比较混乱
6、数据恢复
[root@YoungCheung ~]# mysql -uroot -pxxxxxx <backup.sql [root@YoungCheung ~]# mysql -uroot -pxxxxxx mysql> select * from person; +--------+-------------+------------+ | number | name | birthday | +--------+-------------+------------+ | 1 | zy | 1995-12-26 | | 2 | youngcheung | 1995-04-24 | +--------+-------------+------------+ 2 rows in set (0.00 sec) //此时恢复了全备时刻的数据 //然后使用004.sql文件恢复全备时刻到删除数据库之间,新增的数据 [root@YoungCheung ~]# mysql -uroot -pxxxxxx student <004.sql mysql> select * from person; +--------+-------------+------------+ | number | name | birthday | +--------+-------------+------------+ | 1 | zy | 1995-12-26 | | 2 | youngcheung | 1995-04-24 | | 3 | test1 | 2011-11-11 | | 4 | test2 | 1111-11-12 | +--------+-------------+------------+ 4 rows in set (0.00 sec)
此时,数据恢复成功!
五、小结
适合人为SQL语句造成的误操作或者没有主从复制等的热备情况宕机时的修复
恢复条件要全备和增量的所有数据
恢复时建议对外停止更新,即禁止更新数据库
先恢复全量,然后把全备时刻点以后的增量日志,按顺序恢复成SQL文件,然后把文件中有问题的SQL语句删除(也可通过时间和位置点),再恢复到数据库

神回复
发表评论:
◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。