1      介绍

Percona Xtrabackup是目前比较流行的MySQL热备份工具。其工具集中包括innobackupex、xbcrypt、xbstream、xtrabackup等。比较常用的就是innobackupex和xtrabackup。在2.3版本之前innobackupex是一个perl脚本，其封装了xtrabackup。从2.3版本开始这个脚本的所有功能都在xtrabackup的C程序中实现了，为了向前兼容2.3版本开始innobackupex是一个指向xtrabackup的软连接，并且支持其在2.2版本中的所有特性和语法，在后面的主版本中可能会去掉。

2      Xtrabckup流程介绍

下图是2.3版本的被流程（因为innobackup在这个版本里只是Xtrabackup的一个软连接，图中只展示了Xtrabackup）。

3      2.2.3版本之前的一个问题

Xtrabackup在2.2.3版本之前有一个bug，备份出来的数据库是一致的，没有问题，但是可能会导致备份出来的数据库与binlog位置不一致。当使用binlog的位置的话，会引入一些问题。

https://bugs.launchpad.net/percona-xtrabackup/+bug/1320685

    这个问题是在MySQL5.6的一次代码优化后Xtrabackup才有的。关于事物提交,InnoDB存储引擎层对每个事物进行prepare操作，都需要进行一次fsync操作，以便保证事物的prepare日志写入到了redo日志中。然后，一个组提交中的事物依次向MySQL的二进制日志写日志，这个写操作是缓存写，最后完成一fsync操作。即一个fsync将多个事物的日志写入到了二进制日志，也就是我们通常说的组提交。最后完成InooDB引擎层面的提交操作。5.6的一个优化就是InnoDB引擎层的提交不再进行fsync。

  因为即使InnoDB引擎层的提交操作丢失了，这个事物要做的事情基本已经完成。由于binlog日志已经写入且已经fsync,再恢复时，只需要从binlog中判断最后的事物是提交还是回滚就可以。

  但是对于Xtrabackup是个问题，因为事物最后的提交不再需要fsync,那么其redo日志中可能还没有提交记录。而Xtrabackup对于InnoDB的恢复只是通过redo日志重放来实现。这样，Xtrabackup备份出来的InnoDB数据文件虽然还是一致的，但是数据与binlog的位置可能不一致。那么当要用这个位置时可能会出错，比如搭建从库。

  Xtrabackup在2.2.3版本中解决了这个问题，解决方法也很简单，就是在"完成redo拷贝"前“同步redo到磁盘”。在上图中可以看到，同步redo到磁盘的操作位置。