需求：需要给开发提供一个2018年9月30号的数据，按照我们公司正常备份策略来说，直接找到对应时间的备份数据，解压导入即可，恰好这个时间节点的数据没有，只备份到2018年9月25号的，糟糕了吧
咋办呢，咱们利用binlog日志来恢复吧，如果二进制日志都没有，那还恢复啥呢，运维咋当滴
话不多说，进入正题
一、导入数据
我的源数据：baodian_2018-09-25_329010659.tar.bz2 #这一串数字是pos节点位置，等下利用二进制恢复的时候需要用到，时间：9月 25 01:08
随便在哪个mysql数据库解压导入即可，根据自己的需求就行
二、找到对应的binlog
知道的时间节点：
1.开始pos位置：329010659
2.结束时间：2018-10-01 00:00:00
# 二进制日志分析
2018-09-22 12:34:23.459540935 2018-09-29 15:54:20.554318725 mysql-bin.000163
2018-09-29 15:54:20.554318725 2018-10-04 00:09:50.238484899 mysql-bin.000164
三、数据恢复
利用binlog恢复，一条命令搞定
/usr/local/mysql/bin/mysqlbinlog --start-position=329010659 --stop-datetime='2018-10-01 00:00:00' --database=baodian --set-charset=utf8 mysql-bin.000163 mysql-bin.000164 |mysql -h127.0.0.1 -P3036 -uroot -p123456 baodian
温馨提示：
1.mysqlbinlog分析多个文件的时候，不能分开写，否则导入的时候会报语法错误，如图
2.尽量加上字符集编码参数，否则中文是乱码
我的是： --set-charset=utf8
3. mysqlbinlog分析分时候，不要加这个参数，--base64-output=decode-rows，否则数据导不进去 #当然是根据我的环境来说的
其实我觉得一般是可以的，可能是我my.cnf里面设置了格式为row
4.如果导数据的时候，出现如下两种报错信息
1)ERROR 1609 (HY000): The BINLOG statement of type `Table_map` was not preceded by a format description BINLOG statement. #直接在数据库source的时候
2) ERROR 2006 (HY000) at line xx: MySQL server has gone away #出现这个原因有很多种，其他原因的解决办法参考：https://www.cnblogs.com/fnlingnzb-learner/p/5984795.html
这里的原因是，sql操作时间过长，传送的数据太大，可以设置max_allowed_packed来避免
解决：在my.cnf里面添加一行参数
max_allowed_packed=16M #如果不行将16M再加大
mysqlbinlog其他用法，参考：
https://www.cnblogs.com/kevingrace/p/5907254.html