mysql全量备份+binlog日志完整恢复数据

首先，数据库在误操作之前必须已经开启了binlog日志功能，且binlog日志的保存周期必须大于全备份的时间周期！

所谓恢复，就是让将全备份的数据全部恢复后，再使用mysqlbinlog命令把binlog日志文件从全备份的时间点开始依次执行到误删除的时间点。而mysqlbinlog就是把binlog日志转成SQL语句的一个工具而已。

模拟数据误操作：

第一步：创建了db库，创建一个tb1表，增加1、2、3共三行数据，并使用flush logs手动刷新日志，这样新日志就会写入下一个新文件；

第二步：创建一个tb2表，但是给tb1表再添加了 4、5、6 三行数据。然后手动全备份db库（一般都是通过脚本定时在晚上12点备份）。

第三步：给tb2添加了3、2、1 三行数据 ,再给tb1表添加 7、8、9 。

第四步：给tb1表添加 10、20、30 三行数据。 flush logs手动刷新日志。

第五步：创建tb3表,添加 100、200、300 三行数据
第六步：删除表 tb1 和tb2 和tb3 ，然后立马执行flush logs命令手动刷新日志，并查看最新的binlog日志文件的编号

第七步：分析恢复到删除表之前的操作，都需要使用哪些binlog文件

第八步：将数据恢复到误删除表 tb1 和tb2 和tb3之前的数据。

为什么要手动执行flush logs命令刷新日志：每一个binlog日志都指定大小的，当一个文件超出指定大小的时候就会写到下一个文件。手动执行flush logs命令刷新日志就是模拟全备份时间点到误删除时间点之间，模拟已经有多个binlog日志文件的情况。

本次恢复数据会使用到的命令：

（1）查看binlog日志是否开启，以及日志存放路径

show variables like 'log_%'

（2）查看所有binlog日志列表
show master logs

（3）查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值

show master status

（4）flush刷新log日志，自此刻开始产生一个新编号的binlog日志文件

flush logs

（5）指定展示某一个binlog文件的所有操作。

show binlog events in 'mysql-bin.00000x'

开始模拟：

第一步：

创建了db库，创建一个tb1表，增加1、2、3共三行数据，并使用flush logs手动刷新日志

第二步：创建一个tb2表，但是给tb1表再添加了 4、5、6 三行数据。然后全备份db库

全备份db库：

参数含义：

-B ：指定要备份的库的名字

-F：备份完成后强制刷新binLog日志，让新的日志写入到新的文件中

-R:备份存储过程等

-x：备份每张表之前先锁表

--master-data：在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息

第三步：给tb2添加了3、2、1 三行数据 ,再给tb1表添加 7、8、9 。

tb1表和tb2表的所有数据，如下图：

第四步：给tb1表添加 10、20、30 三行数据。并flush logs手动刷新日志。

第五步：创建tb3表,添加 100、200、300 三行数据

第六步：模拟误删除表 tb1 和tb2 和tb3 ，误删除后立马执行flush logs命令手动刷新日志，并查看最新的binlog日志文件的编号

第七步：分析恢复到删除表之前的操作，都需要使用哪些binlog文件

（1）查看全备份数据中的binlog日志的编号和pos点，一般在备份的文件第20行上下

如下图：第22行可以看到我的此次备份文件是mysql-bin.000003,pos点是154

（2）根据第六步误删除后立马执行flush logs命令手动刷新日志，并查看最新的binlog日志文件编号是mysql-bin.000005,pos点是154，说明误操作所产生的的binlog日志在mysql-bin.000004这个文件中，接下来就要查看mysql-bin.000004中对应删除操作的pos点是哪一个。

（3）如下图：可以看到删除tb1表时的pos号是1128。