mysql数据备份与binlog恢复

binlog 基本认识

MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。

一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景:

其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。

其二：自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。

开始操作了

在[mysqld] 区块

设置/添加 log-bin=mysql-bin

然后执行update操作 delete操作等都会有日志记录到 /usr/local/mysql/data/mysql-bin.000001 当然这个路径是可以修改的

查看所有的事件登录到mysql>show binlogs events in 'mysql-bin.000001';

其中Pos（position）和 end_log_pos 是比较重要的节点

mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

选项解析：

IN 'log_name' 指定要查询的binlog文件名(不指定就是第一个binlog文件)

FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)

LIMIT [offset,] 偏移量(不指定就是0)

row_count 查询总条数(不指定就是所有行)

用mysqlbinlog工具查看（一般是binlog文件过大，无法确定具体时间）

基于开始/结束时间

[root@hd3 ~]# mysqlbinlog --start-datetime='2018-06-21 19:00:00' --stop-datetime='2018-06-21 19:05:00' -d database_name /data/mysql/mysql-bin.000005|grep "delete"

查看binlog中包含字符串的，并展示上下五行。

mysqlbinlog --start-datetime='2018-06-22 09:00:20' --stop-datetime='2018-06-22 09:27:50' -d mlsys /data/mysql/mysql-bin.000007 |grep -C 5 "string"

flush logs; //这个操作会让binlog 使用一个新的文件进行记录

mysqlbinlog --start-position=4 --stop-position=6294 --database=test_test /data/mysql/mysql-bin.000003 |mysql -uweb_user -p

表示使用某个文件，恢复从4起始点到6294截止点的操作。其中指定了数据库，所以其中所有不是该数据库操作的binlog都不会进行操作。在恢复这个操作之前一般会重新指定binlog防止污染原始的日志。

我们来测试一下恢复数据的效率

大概20W条记录，binlog文件85M，pos 87805879

1、使用新的binlog 文件，flush logs;

2、mysqlbinlog --start-position=4 --stop-position=87805879 --database=test_test /data/mysql/mysql-bin.000003 |mysql -uweb_user -p

3、然后就是漫长的等待，最后恢复完花了15分钟。可能是服务器的性能不怎么好，回去用家里的机器试试。

mysql数据备份与binlog恢复

猜你喜欢