目前MySQL的物理备份大多数采用xtrabackupex进行，其备份过程如下图所示，这里通过解析 xtrabackup 的源码来详细看看其是如何进行备份的，xtrabackup 版本为 2.4.26。
在这里，我们只分析完整备份的过程。许多细节可以通过源代码找到。核心备份流程如下：
[En]
Here, we only analyze the process of full backup. Many details can be found through the source code. The core backup process is as follows:
-
从 log group 的 log header 中获取 lastest checkpoint lsn.
-
从 lastest checkpoint lsn 开始从 log group 中拷贝 redo log，直到没有 redo log为止，此时拷贝的 redo log 点位记为 log_copy_scanned_lsn
-
启动后台的 redo log copy 线程，循环从 log_copy_scanned_lsn 点位开始拷贝 redo log 。
-
获取 ibdata1, undo tablespace 和所有的 ibd 文件，根据指定的 --parallel 参数创建并发的拷贝线程，拷贝数据文件。
-
待数据拷贝结束，则加全局读锁。这里有一个小细节，如果 MySQL 支持备份锁，且没有指定 --no-backup-locks，则会优先使用备份锁：LOCK TABLES FOR BACKUP；
如果不能使用备份锁，则走正常的加锁流程，这其中包含 xtrabackupex 防止阻塞逻辑。
5.1. 如果没有指定 kill-long-queries-timeout & ftwrl-wait-timeout，则首先执行 FLUSH NO_WRITE_TO_BINLOG TABLES；这是为了防止因为存在 long update 操作而导致 FTWRL操作阻塞整个MySQL服务。当存在 long update操作，FLUSH TABLES 将被阻塞，但是整个 mysql 服务不会被阻塞。当 long update结束，FTWRL操作会很快结束。