hevenue 2020-06-08
mysql>show VARIABLES like ‘log_bin‘;
2、开启二进制日志功能:
[ ~]# vim /etc/my.cnf #在mysqld字段下写入下面配置,以便开启二进制日志并指定二进制文件名 #开启二进制日志,需要指定server-id,否则服务将会启动失败 log-bin=/usr/local/mysql/data/bin_log server-id=1 [ ~]# systemctl restart mysqld #重启后,将在指定的目录下生成两个文件,如下: [ data]# pwd /usr/local/mysql/data [ data]# ls | grep bin_log bin_log.000001 #每次重启mysql服务或执行flush logs命令,都会生成一个新的这样的文件,依次为000001、000002...... bin_log.index #这个文件存储所有二进制文件的索引
开启二进制日志功能后,所有增删改的操作都会记录到二进制日志文件当中,注意,是增删改的操作,不包括查操作。
3、确定二进制日志功能已开启
mysql>show VARIABLES like ‘log_bin‘;
4、执行增删改以便测试bin_log是否有记录
mysql> reset master; #清空所有的二进制文件,从00001开始 #创建一个库,并在库中创建一个表 mysql> create database test1; mysql> use test1; mysql> create table tb1(id int primary key auto_increment,name varchar(20)); #向表中插入两条数据 mysql> insert into tb1(name) values(‘zhangsan‘); mysql> insert into tb1(name) values(‘lisi‘); #重新开始一个新的日志文件再执行操作。注意,此时上面所有的操作写入的是第一个二进制日志文件 mysql> flush logs; mysql> delete from tb1 where name=‘lisi‘; #删除插入的第二条数据 mysql> insert into tb1(name) values(‘tom‘); #再插入一条新的数据 #以上的操作是写入了第二个日志文件
5、MySQL中查看二进制日志文件及文件内容
查看二进制日志文件:
mysql>show binary logs;
查看二进制日志文件内容:
完整的命令格式如下:
SHOW BINLOG EVENTS[IN ‘log_name‘] [FROM pos] [LIMIT [offset,] row_count] # in:指定要查看的二进制文件; # from:指定从哪个“pos”位置开始查看 # limit:限制返回的行数,offset是指跳过多少行再显示
注:如果不指定二进制文件名,那么默认显示第一个二进制日志文件中的事件,文件内容中包含了日志文件名、事件的开始位置、事件类型、结束位置、信息等内容。
mysql>show binlog events in ‘bin_log.000001‘;
其他命令:
- show master logs:也是查看二进制日志文件;
- PURGE BINARY LOGS:用于删除二进制文件;
.
例子:
- PURGE BINARY LOGS TO ‘mysql-bin.00010‘; #把这个文件之前的其他文件都删除掉
- PURGE BINARY LOGS BEFORE ‘2016-08-28 22:46:26‘; #把指定时间之前的二进制文件删除了
6、使用mysqlbinlog本地查看二进制日志内容
[ data]# pwd /usr/local/mysql/data [ data]# mysqlbinlog bin_log.000001 #使用-v选项可以查看出日志文件中的详细信息,两个v可以查看出更详细的信息,但是三个vvv也不会有什么作用了 [ data]# mysqlbinlog -v bin_log.000001 [ data]# mysqlbinlog -vv bin_log.000001
7、通过二进制日志恢复数据
假设在开始删除lisi记录的那条sql语句是误操作,现在要通过二进制日志来恢复数据。
1)首先需要找到删除lisi记录的sql语句在二进制日志中的位置,每条sql语句都是一个事务,所以需要从其begin到commit,才算是完整的sql语句。如下:
[ data]# mysqlbinlog -v bin_log.000002 | tail -35
从上面可以看出,delete事件发生position是387,事件结束是650。
2)事件恢复流程:直接用bin-log日志将数据库恢复到删除位置219前,然后跳过故障点,再进行恢复下面所有的操作,具体恢复流程如下:
导出相关binlog文件(将二进制文件转换为sql语句生成新的文件):
[ data]# mysqlbinlog bin_log.000001 > /tmp/01.sql [r data]# mysqlbinlog --stop-position=387 bin_log.000002 > /tmp/387.sql [ data]# mysqlbinlog --start-position=650 bin_log.000002 > /tmp/650.sql
上述指令中,第一条比较好理解,无非就是使用msyqlbinlog查看第一个二进制文件,并生成新文件,后面两条指令呢,--stop-postition意思是查看时到219这个位置不查看,一直到393才又开始接着查看。最后的结果就是新生成的文件中不会包含删除lisi记录的sql语句。
3)删除数据库
mysql> drop database test1;
4)利用binlog恢复数据
[ data]# mysql -uroot -p123 < /tmp/01.sql [ data]# mysql -uroot -p123 < /tmp/387.sql [ data]# mysql -uroot -p123 < /tmp/650.sql
5)确定数据已恢复
mysql> select schema(); mysql> select * from tb1;
二、mysqldump备份工具
mysqldump是mysql用于备份和数据转移的一个工具。主要产生一系列的SQL语句,可以封装到文件,该文件包含有所有重建数据库所需要的 SQL命令,如CREATE DATABASE,CREATE TABLE,INSERT等等。可以用来实现轻量级的快速迁移或恢复数据库。 mysqldump 是将数据表导成 SQL 脚本文件,在不同的 MySQL 版本之间升级时相对比较合适,这也是最常用的备份方法。 mysqldump一般在数据量很小的时候(几个G)可以用于备份。当数据量比较大的情况下,就不建议用mysqldump工具进行备份了。
mysqldump可以针对单个表、多个表、单个数据库、多个数据库、所有数据库进行导出的操作。
mysqldump使用示例:
1、备份某一个表
[ backup]# mysqldump -uroot -p123 mysql user > mysql-user.sql #备份mysql库中的user表 [ backup]# ls mysql-user.sql
2、恢复mysql数据库中的user表
[ backup]# mysql -uroot -p123 mysql < mysql-user.sql
3、备份mysql库
[ backup]# mysql -uroot -p123 --databases mysql > mysql.sql [ backup]# ls mysql.sql mysql-user.sql
4、恢复mysql库
[ backup]# mysql -uroot -p123 < mysql.sql
5、备份所有的库(当导出的数据量较大时,可以添加“--opt”选项以优化执行速度)
[ backup]# mysqldump -uroot -p123 --opt --all-databases > all-data.sql [ backup]# ls all-data.sql