mysql 误删数据应用备份与binlog恢复数据
今天测试使用binlog恢复数据时碰到了一个小问题，记录一下。
作者：zhou
mysql版本：5.7
场景模拟误删数据 delete from table;
由于是测试我就没有按文档完全一样的步骤进行，如果是生产环境误删数据建议使用美团的Myflash数据回滚工具或者用我现在使用的备份加binlog的增量数据来恢复数据，今天使用的备份加binlog增量来恢复数据由于delete的增量数据都在一个binlog中我就不使用备份了导入了，如果误删数据在一个或多个binlog中无法提取，需要先把备份导入在解析binlog导入增量数据。
接下来看看mysql 5.7 官方文档的步骤恢复数据。
官方文档地址：
https://dev.mysql.com/doc/refman/5.7/en/point-in-time-recovery-positions.html
按大致的开始时间和结束时间来进行恢复，需要去除具体的delete对应的时间节点日志，可以先解析对应的binlog：
mysqlbinlog -v --start-datetime=“2020-03-31 15:00:00” --stop-datetime=“2020-03-31 17:11:00” mysql-bin.000005 -d test > test.sql
在执行的时候加上 -v 参数 binlog 可以解析为直接看的明白的格式：
可以看到在row格式下binlog解析后有具体的执行时间、position点位还有对应语句的上下文关系，这也是能通过解析binlog进行恢复数据的原因。
过滤对应的delete语句时间：
mysqlbinlog --start-datetime=“2020-03-31 15:00:00” --stop-datetime=“2020-03-31 15:40:00” mysql-bin.000005 -d test > test.sql
这个就是一开始我说的碰到的一个小问题，明明是按照官方文档的步骤恢复的，查看binlog解析的文件也没有问题，为什么导入的时候没有数据呢？
小经波折，翻看了一下文档，发现这是GTID相关的特性，正常解析的binlog再导入的时候 test.sql 这个文件里包含已经执行的GTID点位，然而导入的时候已经执行的GTID是不会重复执行的。
这时候在解析的语句里加一个 --skip-gtids=true 参数即可跳过GTID对应的解析内容。
执行：
mysqlbinlog --start-datetime=“2020-03-31 15:00:00” --stop-datetime=“2020-03-31 15:40:00” mysql-bin.000005 -d test --skip-gtids=true > test.sql
之后source test.sql 进去就好了：
跳过position点位来解析和上面的步骤一样，命令修改为–start-position --stop-position即可。
这个看了不少文章都没有提到这个参数–skip-gtids=true，最后还想吐槽一下mysqlbinlog解析的时候翻看了一下help ，解析的维度只能设定跳过 -d 参数设置，只能过滤到database级别的不能过滤到table级别的，这还是有点不好的设定。
我是zhou,如果需要转发请注明出处。
