因为临时表的原因，--safe-slave-backup需要在SHOW STATUS的输出中slave_open_temp_tables为0的时候才停止slave SQL Thread，否则会导致复制出问题。因为临时表是基于用户session的，因此如果正在操作临时表的数据的时候停止slave SQL Thread，会导致可能后续的数据不一致，在其他停用slave SQL Thread的场景也要注意这个问题。
信息如下：

  　　这是使用XtraBackup容易引起的一个经典错误，引起这个错误的原因也很简单，就是XtraBackup在备完innodb表的时候，要获得对 所有表的锁定来备份MyISAM表和其他文件，来保证数据的一致性，如果在此过程中数据库不断的有DML操作，XtraBackup就可能迟迟无法获得对 所有表的锁定，最后超时。

　　要避免这个问题，一个是加大超时的时间限制，但这显然不是一个好的解决办法，另外就是在备份的时候加上 --no-lock参数，就是在复制MyISAM表和.frm等文件的时候不锁表，但要保证这时没有对MyISAM表的DML操作和Innodb表的 DDL操作，这一般通过应用端权衡时间是容易办到的。

　　但是要注意的是，如果备份出来的文件要用于主从复制，那么不锁表会导致没有输出 slave_info文件和binlog_info文件，这对于一些人的应用场景可能会有影响。这时可以加一个--safe-slave-backup参 数，使得在从库上备份的时候停止SQL THRED，这样即使从库能从主库接收binlog文件，但是不会应用，relay log position就不会移动了。但是单纯的停掉slave SQL Thread是不会影响binlog position的。

XtraBackup是percona公司提供的开源工具，以热备Innodb表著称而被广泛采用。

　　XtraBackup对 Innodb的备份之所以是热备，无需锁表，是基于Innodb自身的崩溃恢复机制，它首先复制所有的Innodb数据文件，这样复制出来的文件肯定是不 一致的，然后对每个文件进行崩溃恢复处理，最终达到一致。就和MySQL在启动Innodb的时候一样，会通过比较数据文件头和redo log文件头信息来检查数据是否是一致的，如果不一致就尝试通过前滚(把redo log中所有提交的事务写入数据文件)和回滚(从数据文件中撤销所有redo log中未提交的事务引起的修改)来使数据达到最终一致。

　 　XtraBackup在启动的时候会记录一个LSN(log sequence number)，然后就把所有的Innodb数据文件复制出来，这样复制出来的数据文件是不一致的，但是XtraBackup会在后台运行一个进程把所有 对redo log file的修改记录下来，只要有了这个数据，就能进行崩溃恢复。只所以要额外记录下来，是因为MySQL自身的redo log file是可重用的。

　　以上的操作是由xtrabackup二进制程序(比如xtrabackup_55)完成的，如果使用 innobackupex 脚本，刚才的步骤完成以后，innobackupex就会去备份MyISAM表和.frm文件，这时要保证数据的一致性就会先锁表了，通过FLUSH TABLES WITH READ LOCK命令锁表然后把文件复制出来，再释放掉这个锁。

　　在恢复数据的时候，要经过 prepare(recovery)和restore两个步骤。在prepare结束以后，Innodb的表恢复到了复制Innodb文件结束的时间点， 这个时间点也就是锁表复制MyISAM表的起点，所以最终数据是一致的。一般我们在恢复的时候执行两次prepare，是因为第二次prepare会帮助 我们生成redo log文件，从而加快MySQL数据库启动的速度。

　　我们再来看一下实际备份的日志来理解这个过程：