1.开启redo日志拷贝线程，从最新的检查点开始顺序拷贝redo日志；
2.开启idb文件拷贝线程，拷贝innodb表的数据
3.idb文件拷贝结束，通知调用FTWRL，获取一致性位点
4.备份非innodb表(系统表)和frm文件
5.由于此时没有新事务提交，等待redo日志拷贝完成
6.最新的redo日志拷贝完成后，相当于此时的innodb表和非innodb表数据都是最新的
7.获取binlog位点，此时数据库的状态是一致的。
8.释放锁，备份结束。
Xtrabackup的改进
从前面介绍的逻辑备份和物理备份来看，无论是哪种备份工具，为了获取一致性位点，都强依赖于FTWRL。这个锁杀伤力非常大，因为持有锁的这段时间，整个数据库实质上不能对外提供写服务的。此外，由于FTWRL需要关闭表，如有大查询，会导致FTWRL等待，进而导致DML堵塞的时间变长。即使是备库，也有SQL线程在复制来源于主库的更新，上全局锁时，会导致主备库延迟。从前面的分析来看，FTWRL这把锁持有的时间主要与非innodb表的数据量有关，如果非innodb表数据量很大，备份很慢，那么持有锁的时间就会很长。即使全部是innodb表，也会因为有mysql库系统表存在，导致会锁一定的时间。为了解决这个问题，Percona公司对Mysql的Server层做了改进，引入了BACKUP LOCK，具体而言，通过"LOCKTABLES FOR BACKUP"命令来备份非innodb表数据；通过"LOCK BINLOG FOR BACKUP"来获取一致性位点，尽量减少因为数据库备份带来的服务受损。我们看看采用这两个锁与FTWRL的区别：
LOCK TABLES FOR BACKUP
作用：备份数据
1.禁止非innodb表更新
2.禁止所有表的ddl
优化点：
1.不会被大查询堵塞(关闭表)
2.不会堵塞innodb表的读取和更新，这点非常重要，对于业务表全部是innodb的情况，则备份过程中DML完全不受损
UNLOCKTABLES
LOCK BINLOG FOR BACKUP
作用：获取一致性位点。
1.禁止对位点更新的操作
优化点：
1.允许DDl和更新，直到写binlog为止。
UNLOCKBINLOG
以上就是本文的全部内容，希望对大家的学习有所帮助。
