binlog详解、binlog恢复数据
mysql5.7默认是不开启binlog日志的，具体的开启方式在开启的笔记中查看。
binlog开启成功之后，binlog文件的位置可以在my.inf配置文件中查看。也可以在mysql的命令行中查看。命令行查看代码如下
show variables like '%log_bin%';
我们也可以看一下当前mysql的binlog的情况
show master status
每当我们重启一次，会自动生成一个binlog文件，我们重启完毕之后再来执行同样的命令
存放binlog的目录下也多个了这么一个文件。
当然，我们也可以手动的来刷新binlog文件，通过 flush logs,同样会新创建一个binlog文件
如果我们想把这些文件全部清空，可以使用reset master 来处理
下面我来看针对单个文件的操作，首先我们想看一下文件的内容
找到binlog的目录，比如我们要看mysql-bin-0001
vi mysql-bin-000001
我们看到的一堆乱码。我们知道这是一堆的二进制文件，所以以文本的方式打开二进制文件一定是有问题的，那么我们该如何查看这个文件的内容呢？
mysql给我们提供了一个用于查看binlog日志的工具，叫做mysqlbinlog
这个文件比较长，一次打开看不完怎么办呢，这里可以使用linux的管道，这里就不详细的说了，可以自己去查找关于linux的一些知识。
注意到上面的截图中有一个position字段，这个字段的值为154，这个表示的就是binlog当前的位置。我们每次执行dml操作，position都会改变。比如我们先来创建一个数据 test
在创建之前我们可以清一下binlog日志方便我们查看，可以使用 reset master。在生产环境中，这个操作是非常危险的，那么我们可以使用flush logs来处理，生成一个新的binlog文件。不管采用哪种方式，我们在测试的环境中，只要有一个新的binlog文件就可以了。生成了新的binlog文件之后，我们可以通过show master status 来查看状态
下面我们来执行一个dml语句，比如我们要创建一个test数据库
create database test;
然后我们来查看创建之后的状态，如下，我们发现position从154变成了313，也就是说我们的操作是在154到313之间，然后我们再来看binlog的内容。
我们截取154到313之间的binlog的内容如下：
# at 154 #170708 9:24:02 server id 12345 end_log_pos 219 CRC32 0x30763ffe Anonymous_GTID last_committed=0 sequence_number=1 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/; # at 219 #170708 9:24:02 server id 12345 end_log_pos 313 CRC32 0x4d0140b3 Query thread_id=5 exec_time=0 error_code=0 SET TIMESTAMP=1499477042/*!*/; SET @@session.pseudo_thread_id=5/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1436549152/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/;我们可以看到，mysql做了很多的隐含的操作，然后加粗的部分就是我们所执行的操作。
下面我们来简单总结一下关于binlog：
1.binlog文件会随服务的启动创建一个新文件
2.通过flush logs 可以手动刷新日志，生成一个新的binlog文件
3.通过show master status 可以查看binlog的状态
4.通过reset master 可以清空binlog日志文件
5.通过mysqlbinlog 工具可以查看binlog日志的内容
6.通过执行dml，mysql会自动记录binlog
我们了解了MySQL的binlog日志的开启方式以及binlog日志的一些原理和常用操作，我们知道，binlog有两大作用，一个是使用binlog恢复数据，另一个就是用来做主从复制。本篇笔记就是来记录如何使用binlog日志来做数据恢复。当然了，使用binlog日志所恢复的数据只能是部分数据，并不能够使用binlog日志来做数据库的备份，如果想要做数据库备份，依然要使用我们传统的备份方法，而binlog可以作为增量备份。
在正式开始之前，先来说一说mysql完整备份数据库，以及恢复数据库的方法
备份数据库：
首先我们来创建一个数据库，mytest
create database mytest;
接着我们来创建一张表
use mytest;
create table t1(id int ,name varchar(20));
然后我们插入两条数据
insert into t1 values (1,'xiaoming');
insert into t1 values (2,'xiaohong');
下面我们对mytest数据库进行备份，备份到/root/bakup/
mysqldump -uroot -p -B -F -R -x --master-data=2 mytest | gzip > /root/backup/bak_$(date +%F).sql.gz
参数说明：
-B：指定数据库
-F：刷新日志
-R：备份存储过程等
-x：锁表
--master-data：在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息
查看备份文件
这样呢，我们就把数据做了一个完整的备份。下面来删除数据库，然后通过备份数据进行恢复数据库。
gzip -d bakup_xxx.gz
mysql -uroot -p < bakup_xxx.sql
这样我们就把数据导入到库里了。
继续上面的操做，我们新增xiaoli和xiaozhao这两条数据，并把xiaozhao这条记录删除掉。
在删除之前，我们先来刷新binlog日志，生成一个新的日志，那么我们之后所要操做的内容都会被记录到新的日志文件中。（通过前面binlog日志的详细说明我们知道，每次刷新和服务重启的时候，都会生成一个binlog日志文件。）
flush logs;
show master status;
我们注意，binlog的文件是0009，位置是在154，这两个信息很重要
下面我们来做插入和删除操作
这个时候我们应该是来查看一下binlog日志的状态，以便与我们一会来进行恢复到此状态，但是，真正的环境中我们并不知道这个状态，因此这里也就不去查看这个状态了，这个状态的值可以通过后面查看binlog日志文件来进行分析。下面我们开始误操作：
我们来把xiaozhao删除掉
这样数据就删除掉了，下面我们再来查看binlog的状态
show master status;
这个时候我们发现我删除操作是个错误的操作，要进行恢复，那么该如何恢复呢？这个时候我们就可以通过binlog的position来进行恢复。 在进行其他的处理之前，我们建议，马上再执行一次flush logs，也就是让出错的部分就集中在这么一个binlog日志文件中。
我们来查看0009的binlog日志。