玩转binlog实现灵活的MySQL数据恢复

我们知道binlog是mysql数据库的所有event记录，相当于oralce的redo和归档。

在数据库运行过程中会源源不断地产生binlog文件，并且默认情况下这些文件是不会删除的。

那么根据理论，这些完全保留了数据库的历史变化，甚至从数据库初始化开始就保留了所有的event记录。

如果对这些binlog文件加以适当的保护，就可以利用这些binlog文件在任何情形下恢复我们的数据。

mysql提供一个工具：mysqlbinlog，来提取binlog的event记录，比如：

下面介绍一下关键点信息，这些极为重要。

# at 120，表示offset为120的event开始，在下一个 # at 结束，我们恢复时指定--start-position=120 就是从这里开始。

#160316 16:33:14，表示时间，我们恢复时指定--start-datetime就是这儿。

server id 2，表示这个event是server_id为2的实例执行的，对于链式或者循环复制是极其重要的。

end_log_pos 221，表示要注意，他是指下一个event的offset是221，意思就是offset的编号并不连续。

椭圆框住的“drop database monitor”就是120这个offset的event实际执行的语句。

我们在数据库恢复时往往需要跳过某些语句，比如我们发现monitor实际是误删除的，那么在重演数据库时，必须指定start-position和end-position以跳过这样的event。

另外，每一个binlog的开头都有一个# at 4 的event，这个是binlog的内部结构（设置参数什么的），实际无意义。并且也无法跳过。

下面谈谈增量备份：

mysql的增量备份也正是基于binlog文件的。所以，我们只要备份至上次全备以来的所有binlog文件，其实就实现了myql的增量备份。

但是在备份binlog文件时，一定要注意避免binlog文件的不一致的情况，否则备份就是无效的。

并且更要注意同一个binlog不能备份多次或者被多次重演。否则恢复或者重演会失败。

著名的percona-xtrabackup工具也是基于binlog文件和position实现的增量备份。我所在的库不超过百gb，所以没有用这个三方工具。

并且每晚把binlog传输到异地，并演进备份库，还可以测试binglog的有效性，也实现数据冗余的目的。

PS，binlog文件里是否会存在不完整的事务？或者使用binlog文件重演数据库时，遇到不完整的事务怎么办？