一、确保mysql开启了binlog日志功能
在/etc/my.cnf文件里的[mysqld]区块添加：
#这个是存储的位置为mysql配置文件的位置
log-bin=mysql-bin
然后重启mysql服务生效
二、创建数据库
先创建一个ops数据库
createdatabaseops;
useops;
创建一个customers表并写上表结构
createtablecustomers(
idintnotnullauto_increment,
namechar(20)notnull,
ageintnotnull,
primarykey(id)
)engine=InnoDB;
查看创建好的表
desccustomers;
表中插入数据：
insertintocustomersvalues(1,"wangbo","24");
insertintocustomersvalues(2,"guohui","22");
insertintocustomersvalues(3,"zhangheng","27");
检查插入数据：
select*fromcustomers;
三、进行数据库全量备份
mysqldump-uroot-p-B-F-R-x--master-data=2ops|gzip>/alidata/mysql_bakcup/ops_$(date+%F).sql.gz
ls/alidata/mysql_bakup
参数说明：
-B:指定数据库
-F：刷新日志
-R：备份存储过程等
-x：锁表
--master-data：在备份语句里添加CHANGEMASTER语句以及binlog文件及位置信息
四、再次插入数据
insertintocustomersvalues(4,"liupeng","21");
insertintocustomersvalues(5,"xiaoda","31");
insertintocustomersvalues(6,"fuaiai","26");
查看最新插入的数据
select*fromcustomers；
五、模拟误操作、删除ops数据库
dropdatabaseops;
此时,全备之后到误操作时刻之间，用户写入的数据在binlog中，需要恢复出来！
查看全备之后新增的binlog文件
cd/alidata/mysql_bakcup
#解压出已经备份好的数据库
gzip-dops_2019-04-23.sql.gz
ls
查看数据库变化的时刻
grepCHANGEops_2019-04-23.sql
这是全备时候的binlog文件位置mysql-bin.000006的第106行
因此在该文件之前的binlog文件中的数据都已经包含在这个全备的sql文件中了
移动到binlog文件，并导出sql文件，提出其中的drop语句
查看mysql数据存放目录，由如下信息可知在/var/lib/mysql目录下
ps-ef|grepmysql
cd/var/lib/mysql
cpmysql-bin.000006/alidata/mysql_bakcup/
cd/alidata/mysql_bakcup/
mysqlbinlogmysql-bin.000006>006bin.sql#即将binlog日志转化为可正常导入的sql文件
vim006bin.sql删除里面drop语句
注意：在恢复全备数据之前必须将binlog文件移出，否则恢复过程中，会继续写入语句到binlog，最终导致增量恢复数据部分变的比较混乱
六、恢复数据
mysql-uroot-p<ops_2019-04-23.sql
查看数据库，看看ops库在不在
showdatabases
useops；
select*fromcustomers;
#此时恢复了全备时刻时候的数据
接着，使用006bin.sql文件恢复全备时刻到删除ops数据库之前，新增的数据
mysql-uroot-pops<006bin.sql
再次查看数据库，发现备份到删除数据库之前的那部分数据也恢复了！
select*fromcustomers;
以上就是mysql数据库增量数据恢复的实例过程！
最后总结几点：
1）本案例适合认为SQL语句造成的误操作或者没有主从复制等热备情况宕机时的修复
2）恢复条件为mysql要开启binlog日志功能，并且要全备和增量所有数据
3）恢复时建议对外定制更新，即禁止更新数据库
4）先恢复全量，然后把全备时刻点以后增量日志，按顺序恢复成SQL文件，然后把文件中有问题的SQL语句删除，在恢复到数据库