http://xiaorenwutest.blog.51cto.commysql
MySQL数据库的灾难恢复与备份sql
数据库对于公司来讲是重中之重;记录着公司的庞大数据,关系到公司的财产,以及客户的资料,若是一旦丢失将会为公司形成没法估量的损失。数据库
可是若是作好备份工做能够避免这种状况的发生;因此说做为一名合格的DBA人员来讲掌握数据库的备份和回复是必不可少的技能。另外在工做当中公司也会进行一些计划:好比说数据库的灾难与恢复的测试。今天为你们带来的就是关于MySQL的备份与恢复。服务器
一:咱们在这里采用的是mysqldump工具进行备份:ide
mysqldump备份结合binlog日志恢复工具
这里咱们须要知道的是mysql备份通常采用的是全库备份加日志备份的方式,好比说每周执行一次全库备份,天天执行一次二进制备份,这样当MySQL发生故障的时候能够还原到故障以前的任意位置和时间。post
1)binlog日志:学习
相信你们都知道binlog日志是用来记录数据库发生了改变的日志;好比增、改、删等sql语句,另外在主从复制的时候也须要开启此日志。测试
开启binlog日志的方式:大数据
/etc/my.cnf主配置文件当中开启:
以后保存文件,重启MySQL服务
让咱们看一下,是否已经开启了binlog服务呢?
其中;filename参数指定二级制文件的文件名,其形式为filename.number,number的形式为000001、000002等。每次重启mysql服务或运行mysql> flush logs;都会生成一个新的二进制日志文件,这些日志文件的number会不断地递增。除了生成上述的文件外还会生成一个名为filename.index的文件。这个文件中存储全部二进制日志文件的清单又称为二进制文件的索引
让咱们看一下:
在这里咱们对binlog日志进行个总结:
1:记录数据库发生改变的sql语句
2:能够主从复制
3:最主要的是能够恢复丢失的数据
bin-log由于是二进制文件,不能经过文件内容查看命令直接打开查看,mysql提供两种方式查看方式,在介绍以前,咱们先对数据库进行一下增删改的操做,不然log里边数据有点空。
#mysql -uroot -p -e "reset master"=========>删除全部的二进制文件,重新生成一个新的二进制文件
#mysql -uroot -p -e "create database test"=============>建立一个test的数据库
#mysql -uroot -p -e "use test;create table tb1(id int primary key auto_increment,name varchar(20))"==========>在test数据库当中新建表tb1;ID为自动增加和name
#mysql -uroot -p -e "insert into test.tb1(name) values('lisi')"==========>在tb1表中插入用户lisi
#mysql -uroot -p -e "insert into test.tb1(name) values('zhangsan')"==========>再次插入用户zhangsan
让咱们看一下上面的操做是否成功
接下来咱们从新在生成一个binlog的日志文件:而后将以前的用户ID为2(zhangsan)的用户删掉,以后在建立一个用户为Tom的人员。
#mysql -uroot -p -e "flush logs"
#mysql -uroot -p -e "delete from test.tb1 where id=2"
#mysql -uroot -p -e "insert into test.tb1(name) values('tom')"
# mysql -uroot -p -e "select * from test.tb1"
如今让咱们看一下数据库当中还有谁存在:
接下来让咱们看一下咱们的二进制日志文件当中的内容;以及如何进行恢复:
能够看到如今咱们只有两个二进制日志文件:
接下来咱们查看下二进制日志文件当中的信息
mysql> show binlog events;
默认显示可找到的第一个二进制日志文件中的事件,包含了日志文件名、事件的开始位置、事件类型、结束位置、信息等内容
Format_desc | //此事件为格式描述事件
Query //为查询事件
Table_map //为表映射事件
Write_rows //为咱们执行的insert事件
Xid //Xid时间是自动提交事务的动做
Rotate //为日志轮换事件,是咱们执行flush logs开启新日志文件引发的。
刚才查看的是默认的二进制文件为000001;接下来咱们查看下第二个二进制文件
mysql> show binlog events in 'mysql-bin.000002';
另外换能够经过show binlog events in 'mysql-bin.000002' from 219 limit 1,3;语句查看从219到301的数据,这里不在演示,在文章的后面我会为你们介绍几条sql的语句
接下来咱们开始进行数据的恢复{恢复以前删掉的ID=2的用户}
不管是本地二进制日志文件仍是远程服务器上的二进制日志文件,不管是行模式、语句模式仍是混合模式的二进制日志文件,被mysqlbinlog工具解析后均可直接应用与MySQL Server进行基于时间点、位置或数据库的恢复。
恢复步骤:
首先查看binlog文件:从中找到delete from test.tb1 where id=2这条语句
# cd /usr/local/mysql/data/
# mysqlbinlog -v mysql-bin.000002
从中能够看出delete事件发生position是287,事件结束position是416
恢复流程:直接用bin-log日志将数据库恢复到删除位置287前,而后跳过故障点,再进行恢复下面全部的操做,命令以下
因为以前没有作过全库备份,因此要使用全部binlog日志恢复,因此生产环境中须要很长时间恢复,导出相关binlog文件
#mysqlbinlog /usr/local/mysql/data/mysql-bin.000001 > /opt/mysql-bin.000001.sql
#mysqlbinlog --stop-position=287 /usr/local/mysql/data/mysql-bin.000002 > /opt/287.sql
#mysqlbinlog --start-position=416 /usr/local/mysql/data/mysql-bin.000002 > /opt/416.sql
接下来是见证奇迹的时候到了;接下来往下看
删除test数据库
mysql>drop database test;
利用binlog恢复数据
#mysql -uroot -p< /opt/mysql-bin.000001.sql
#mysql -uroot -p< /opt/287.sql
# 恢复完成后,咱们检查下表的数据是否完整
zhangsan用户已经成功的恢复了,说明此次备份成功了,在这里为你们介绍几个命令让你们参考一下
mysqlbinlog 选项示例
常见的选项有如下几个:
--start-datetime
从二进制日志中读取指定时间戳或者本地计算机时间以后的日志事件。
--stop-datetime
从二进制日志中读取指定时间戳或者本地计算机时间以前的日志事件。
--start-position
从二进制日志中读取指定position 事件位置做为开始。
--stop-position
从二进制日志中读取指定position 事件位置做为事件截至
刚才咱们使用的mysqlbinlog记下来为你们接单的介绍下;
语法格式: mysqlbinlog [options] log_file ...
输出内容会因日志文件的格式以及mysqlbinlog工具使用的选项不一样而略不一样。
mysqlbinlog的可用选项可参考man手册。
二进制日志文件的格式包含行模式、语句模式和混合模式(也即有服务器决定在什么状况下记录什么类型的日志),基于语句的日志中事件信息包含执行的语句等,基于行的日志中事件信息包含的是行的变化信息等。混合模式的日志中两种类型的事件信息都会记录。
为了便于查看记录了行变化信息的事件在当时具体执行了什么样的SQL语句可使用mysqlbinlog工具的-v(--verbose)选项,该选项会将行事件重构成被注释掉的伪SQL语句,若是想看到更详细的信息能够将该选项给两次如-vv,这样能够包含一些数据类型和元信息的注释内容,如
先切换到binlog所在的目录下
#mysqlbinlog mysql-bin.000001
#mysqlbinlog -v mysql-bin.000001
#mysqlbinlog -vv mysql-bin.000001
另外mysqlbinlog和能够经过--read-from-remote-server选项从远程服务器读取二进制日志文件,这时须要一些而外的链接参数,如-h,-P,-p,-u等,这些参数仅在指定了--read-from-remote-server后有效。
另外其余的一些参数能够经过mysqlbinlog --help查看若是看更详细的可使用man手册
2)mysqldump工具的介绍:
主要是用来备份和数据转移的工具,主要产生一系列的sql语句,能够分装到文件,而分装的这个文件主要用于重建数据库所需的sql命令,能够用来实现轻量级的快速迁移或恢复数据库。mysqldump 是将数据表导成 SQL 脚本文件,在不一样的 MySQL 版本之间升级时相对比较合适,这也是最经常使用的备份方法。
mysqldump主要用于数据量很小的时候能够备份,当数据量庞大的时候就显得力不存心了,就不建议使用mysqldump工具进行备份,后续会为你们带来新的备份工具。
mysqldump能够针对单个表、多个表、单个数据库、多个数据库、全部数据库进行导出的操做
#mysqldump [options] db_name [tbl_name ...] //导出指定数据库或单个表
#mysqldump [options] --databases db_name ... //导出多个数据库
#mysqldump [options] --all-databases //导出全部
mysqldump -uroot -p --flush-logs test > /opt/test.sql //--flush-logs这个选项就会完整备份的时候从新开启一个新binlog
数据库的导入
在前面咱们介绍了mysql的binlog和mysqldump工具,下面咱们来学习如何实现mysqldump全库备份+binlog的数据恢复
环境准备与备份还原:
检查开启binlog
先建立一些原始数据
mysql> reset master;===========清除以前的全部二进制文件,而且生成一个新的二进制文件
mysql> create database test_db;===========建立一个test_db的库
mysql> use test_db;==================进入test_db库
mysql> create table tb1(id int primary key auto_increment,name varchar(20));=======建立tb1表
mysql> insert into tb1(name) values('tom1');==============在表中插入数据tom1
mysql> insert into tb1(name) values('tom2');==============在表中插入数据tom2
mysql> commit;===========完成
查看下表中的内容:
前期准备工做已经就绪,如今开始进入备份的工做环节:
方案:mysqldump全库备份+binlog还原
1、mysqldump备份方案:
每周一凌晨1点全库备份
2、备份步骤
(1) 建立备份目录
# mkdir /opt/mysqlbackup
# mkdir /opt/mysqlbackup/daily
(2)全库备份
这里咱们模拟周一的完整备份数据库任务
#mysqldump -uroot -p --flush-logs test_db > /opt/mysqlbackup/test_db_2017_06_24.sql
[root@localhost data]# ls -l /opt/mysqlbackup/
-rw-r--r--. 1 root root 1871 Sep 13 21:06 test_db_2017_06_24.sql
备份mysqldump全库备份以前的binlog日志文(注:生产环境中可能不仅一个binlog文件)
# cp /usr/local/mysql/data/mysql-bin.000001 /opt/mysqlbackup/daily/
# mysql -uroot -p -e "purge binary logs to 'mysql_bin.000002'"
接下来模拟操做失误,将数据修改错误:
mysql> insert into tb1(name) values('tom3');
mysql> commit;
备份自mysqldump以后的binlog日志文件
上面的模拟的误操做是删除了id=1的记录
(3)如今咱们使用mysqldump的全库备份和binlog来恢复数据。
使用mysqldump的备份进行全库恢复
# mysql -uroot -p test_db < /opt/mysqlbackup/test_db_2017_06_24.sql
查询一下数据
[root@localhost ~]# mysql -uroot -p -e "select * from test_db.tb1"
从显示结果能够看到使用mysqldump备份将数据还原到了备份时的状态,刚才删除的数据(id=2)恢复回来了,但备份后产生的数据却丢失了(tom3)因此还得利用binlog进一步还原
由于删除是在全库备份后发生的,而mysqldump全库备份时使用--flush-logs选项,因此只须要分析全库备份后的binlog即mysql_bin.000002。
先查看下binlog的信息:
查看mysql-bin.000002中的事件,能够看到有删除事件
mysql> show binlog events in 'mysql_bin.000002';
使用mysqlbinlog 命令能够查看备份的binlog文件的详细事件。
恢复流程:咱们直接用bin-log日志将数据库恢复到删除位置前,而后跳过故障点,再进行恢复删除后的全部操做。
若是想看的在详细点能够经过
# mysqlbinlog -v /opt/mysqlbackup/daily/mysql_bin.000002语句查看,你们若是还不太了解,这里能够在演示一遍:
经过mysqlbinlog命令所显示的结果能够看到误操做delete的开始postion为219,结束position是422。
从二进制日志中读取指定position=219事件位置做为截至,即把数据恢复到delete删除前
# mysqlbinlog --stop-position=219 /opt/mysqlbackup/daily/mysql-bin.000002 | mysql -u root -p
从二进制日志中读取指定position=422事件位置做为开始,即跳过删除事件,恢复删除事件以后对数据的正常操做
#mysqlbinlog --start-position=422 /opt/mysqlbackup/daily/mysql-bin.000002 | mysql -u root -p
查看恢复结果:
从上面显示能够看出数据恢复到正常状态
为咱们今天的mysql灾难备份与恢复作个总结:
1)介绍了binlog日志文件的做用,以及打开方式,另外里面包括了咱们对数据库的修改sql语句,它是以每个单独的事件存储在里面的
2)mysqlbinlog工具,主要用来打开binlog日志的工具,能够查看更加详细的信息经过-vv选项;另外也能够给binlog日志二进制文件进行备份
3)mysqldump工具;能够用来备份二进制文件,但只适合少许的数据,庞大的数据量就不太适用了
4)其实恢复就是经过二进制文件查看到以前的命令,将删除或者操做错误的命令的那一段事件跳过去而执行其余没有问题的sql语句。
生产环境中Mysql数据库的备份是周期性重复的操做,因此一般是要编写脚本实现,经过crond计划任务周期性执行备份脚本,这是下次为你们带来的,有什么不足但愿你们多多指教