原文地址：http://www.innomysql.net/article/25590.html

前言

淘宝3月的数据库内核月报对 xtrabackup的备份原理 做了深入的分析，写的还是很不错。不过Inside君在看完之后，感觉没有对一个细节问题进行比较深入的介绍。而此问题可能会导致备份文件恢复后丢失相关数据，之前Inside君在 MySQL 5.6对于Xtrabackup的影响 一文中已经做了简单的说明，今天借着淘宝数据库内核组的文章再拿来提醒下各位小伙伴。Inside君还是先给出结论：尽可能地使用新版本Xtrabackup工具备份MySQL数据库。

正文

在淘宝数据库内核组的文章中写到Xtrabackup在备份结束时会按下面的步骤执行操作（有所简化，具体见原文）：

• FLUSH TABLES WITH READ LOCK(FTWRL)
• 拷贝所有非事务表，如系统MyISAM表
• 拷贝重做日志
• UNLOCK TABLES

但是这里少了一个步骤，那就是在拷贝重做日志前，备份工具还会去执行如下操作，该操作会将InnoDB层的重做日志持久化到磁盘然后再进行拷贝：

<span>FLUSH</span> <span>NO_WRITE_TO_BINLOG</span> <span>ENGINE LOGS</span>

这个细节非常关键，因为不执行该操作可能会导致备份丢失一部分的数据，然后再进行主从复制的话，同步可能报错。如果要分析原因，还是得从下面的提交过程图来看：

在上图显示的事务提交过程中，1这个步骤会进行一次fsync，确保日志落盘。但是从MySQL 5.6版本开始，已经不再需要2这个步骤执行fsync了，少了这样的I/O操作可以提升数据库的性能，而这对数据一致性是没有影响的，因此已经写入到二进制日志的事务在恢复的过程中一定是提交的。然而，问题在于Xtrabackup并不拷贝二进制日志。那么就有可能在恢复过程中存在下面的这种情况：

也就是说如果Xtrabackup备份的时候没有备份上图左边的最后一个InnoDB的commit log，这个事务在恢复的过程中就会丢失，简单来说就是数据丢失。Xtrabackup 2.2.3版本修复了此问题，具体可见： https://launchpad.net/percona-xtrabackup/2.2/2.2.3-ga

另外一个小细节是Xtrabackup备份是，如果数据库是Percona Server分支版本的话，那么其使用的不是FLUSH TABLE WITH READ LOCK来获取位置信息，这样的需要把表都关了，而且InnoDB表这时也将不可写入。因此Percona Server版本新增了两个新的命令LOCK TABLES FOR BACKUP和LOCK BINARY LOG FOR BACKUP，因此备份流程变为了：

LOCK TABLES FOR BACKUP

... copy .frm, MyISAM, CSV, etc. ...

LOCK BINLOG FOR BACKUP

UNLOCK TABLES

... get binlog coordinates ...

... wait for redo log copying to finish ...

UNLOCK BINLOG

按照上述逻辑实现的话，InnoDB表只会在备份的最后获取二进制日志位置时被锁住，相对原来的实现锁定的时间又有进一步的缩短，当然这取决于你非事务表的数量，如果全是InnoDB存储引擎用户表的话，那么提升也是有限的。

研究备份实现原理还是非常有意思的一件事情，比如增量备份的实现其实还存在另一些细节可挖掘。若有小伙伴想进一步掌握内部的实现原理，可以去GitHub上翻看下Xtrabackup的源码哦~~~