binlog实现数据备份：二进制日志
在mysql中，我们称二进制日志为binlog，它记录了所有修改了数据库的语句，或者有可能会改变数据库的语句，换句话说，select、show这种不修改数据库的操作，二进制日志是不会进行记录的，二进制日志主要用于时间点恢复（备份恢复），以及主从复制结构。
二进制日志相关概念
我们先聊聊binlog是怎样用于时间点恢复的。
假如我们每天晚上12点进行一次数据库备份，此处不考虑数据量，备份时间等其他因素，那么在本次备份完成后到下次备份开始前的这段时间段中，如果数据库服务崩溃了，我们应该怎样恢复呢？
如果我们只依靠上一次的数据库备份进行恢复，那么我们最多只能恢复到上一个12点时的数据，但是12点以后的数据则会丢失，所以，我们还需要依靠二进制日志（binlog），我们先用上一次的备份将数据库恢复至最近一次12点时的样子，再利用binlog，将12点之后的所有操作”重放”一遍，由于上次备份之时到数据库崩溃之时之间的所有操作完完全全的重新执行了一遍，所以我们可以将数据库中的数据恢复至崩溃之时的样子，而不至于丢失数据，这就是binlog用于恢复时的作用，如果你使用过oracle，那么你肯定会认为，mysql中的binlog与oracle中的归档日志特别像，其实它们存在的目的都是差不多的。
二进制日志有3种记录方式，三种方式如下：
statement模式：记录对数据库做出修改的语句，比如，update A set test=’test’,如果使用statement模式，那么这条update语句将会被记录到二进制日志中，使用statement模式时，优点是binlog日志量少，IO压力小，性能较高，缺点是为了能够尽量的完全一致的还原操作，除了记录语句本身以外，可能还需要记录一些相关的信息，而且，在使用一些特定的函数时，并不能保证恢复操作与记录时完全一致。
row模式：记录对数据库做出修改的语句所影响到的数据行以及这些行的修改，比如，update A set test=’test’，如果使用row模式，那么这条update语句所影响到的行所对应的修改，将会记录到binlog中，比如，A表中有1000条数据，那么当执行这条update语句以后，由于1000条数据都会被修改，所以会有1000行数据被记录到二进制日志中，以及它们是怎样被修改的，使用row模式时，优点是能够完全的还原或者复制日志被记录时的操作，缺点是记录日志量较大，IO压力大，性能消耗较大。
mixed模式：混合使用上述两种模式，一般的语句使用statment方式进行保存，如果遇到一些特殊的函数，则使用row模式进行记录，这种记录方式被称之为mixed，看上去这种方式似乎比较美好，但是在生产环境中，为了保险起见，一般会使用row模式。
简单来说：statement记录语句，row记录语句及修改后的结果，mixed是前两者混合
目前mysql默认是一个MIXED模式
默认binlog是关闭状态的打开的话需要进vim /etc/mysql/mariadb.conf.d/50-server.cnf 在mysqld下添加log_bin=mysqlbin即可，等号后边的是自己取的名字
重启数据库后在该目录下生成binlog文件，后期需要依靠该文件来进行恢复
那么我们现在来模拟生产环境，创建一个数据库、表、以及数据
MariaDB [(none)]> create database oupeng;
MariaDB [(none)]> use oupeng;
MariaDB [oupeng]> create table member (
-> id int(10) unsigned not null primary key auto_increment,
-> name varchar(20) not null,
-> age int(3) not null default 18,
-> works varchar(30) not null
-> );
查看添加后的数据
实现数据库全量备份，假设时间为早上6点备份的
mysqldump -uroot -p -B -F -x --master-data=2 oupeng|gzip > /tmp/oupeng_$(date + '%Y%m%d').sql.gz
白天我们做了一些修改
我们去添加1条数据，修改2条数据
? 当我们不小心删除数据库后，先恢复原来备份的数据，恢复到早上6点备份的数据
首先解压
gzip -d oupeng_.sql.gz
将解压后的数据先恢复
剩下的数据依靠binlog查看进行了哪些操作
去分析0000003日志文件查看进行了哪些操作
编辑备份后的文件，删除drop那条语句
然后进行恢复即可
