Xtrabackup 介绍

Xtrabackup 介绍：

Xtrabackup是Percona团队开发的用于MySQL数据库物理热备份的开源备份工具，具有备份速度快、支持备份数据压缩、自动校验备份数据、支持流式输出、备份过程中几乎不影响业务等特点，是目前各个云厂商普遍使用的MySQL备份工具。

Xtrabackup备份官方MySQL流程：

1、兼容性检查： Xtrabackup社区版本只支持 MyISAM , InnoDB , CSV , MRG_MYISAM 四种存储引擎的表，其他存储引擎的表不会备份；在这一步中，通过查询tables，若发现存在表的存储引擎不是上述四种引擎之一，会打印warning, 表明Xtrabackup不会备份该表。

2、启动redo后台备份线程：启动redo后台备份线程，从备份实例的最近一次checkpoint LSN的位置开始备份所有增量的redo log，一直持续到备份任务结束。

3、加载所有的innodb表空间：打开并扫描所有innodb表的数据文件，检查所有表空间的第一个页面，初始化所有表的内存结构。

4、备份innodb表：遍历步骤3所构建的表的内存结构，备份每一个innodb表的数据文件，备份的过程中会检查每个页面的数据是否正确。

5、加备份锁 FLUSH TABLES WITH READ LOCK (FTWRL)：FTWRL锁是MySQL实例级的读锁，加锁过程复杂，且加锁之后，所有表的所有更新操作以及DDL都会堵塞。

6、备份非innodb表：因为在步骤5我们已经对实例加了读锁，因此，此时备份非innodb表是安全的，此时一定没有写业务。

7、记录binlog当前的GTID信息：请注意，此时我们仍持有全局读锁。这一步主要是方便我们使用该备份集快速地创建出备机。

8、停止redo备份线程。

9、释放锁资源，备份结束。

1. 兼容性检查阶段
   问题现象：Xtrabackup启动后，立即长时间“挂起”，查看日志发现redo log备份线程也没有启动。
   原因：Xtrabackup兼容性检查时无法获取MDL锁。Xtrabackup兼容性检查是通过查询 imformation_schema.tables这个插件表实现：

“SELECT CONCAT(table_schema, '/', table_name), engine FROM information_schema.tables WHERE engine NOT IN ('MyISAM', 'InnoDB', 'CSV', 'MRG_MYISAM') AND table_schema NOT IN ('performance_schema', 'information_schema', 'mysql')”

在查询每张表时，需要获取对应表的MDL锁，如果此时MySQL实例中存在长时间的DML或者DDL 语句，或者更严重者出现了MDL死锁，上面的查询会一直堵塞在等待MDL锁阶段，此时 Xtrabackup会长时间“挂起”。

解决办法：若等待锁的原因只是因为其他SQL语句的堵塞，等待其他SQL执行完成即可；若是发生了死锁，此时需要分析出死锁原因，将死锁解除；华为云RDS for MySQL提供了MDL锁视图功能，可以很好地帮助用户分析业务的MDL死锁。

2.redo log备份阶段
问题现象1：redo log回卷，备份失败，Xtrabackup报如下错误信息：
“xtrabackup: error:it looks like InnoDB log has wrapped around before xtrabackup could process all records due to either log copying being too slow, or log files being too small.\n");”

原因：在备份的过程中，如果主机业务负载很高，导致redo log写入的速度很快，会发生Xtrabackup的redo log备份线程的备份速度小于redo log的写入速度，因为MySQL redo log文件写入使用了 round-robin的方式，使得新写入的日志覆盖了之前写入却还未备份的日志，因此备份失败。

解决办法：推荐在业务低峰期进行备份，或者增大redo log的文件大小。

问题现象2：备份因DDL操作失败，错误信息如下：
“An optimized (without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet.

PXB will not be able take a consistent backup. Retry the backup operation”

原因： 备份过程中MySQL实例发生了创建索引的DDL操作，因为创建索引不会写redo，若继续备份会引起数据不一致问题，所以Xtrabackup在这种场景中备份失败是预期行为。

解决办法：不要在备份过程中创建索引，如果确实需要，建议在建表语句中直接带上索引，或者使用 lock-ddl 参数进行备份(阻塞实例上新的DDL操作)。

问题现象3：undo truncate导致备份失败，Xtrabackup错误信息如下：
“An undo ddl truncation (could be automatic) operation has been performed.”

原因：在Xtrabackup备份期间，如果MySQL实例发生undo truncate时，有可能会出现写入新 undo文件(space id不同)的undo日志丢失导致恢复出来的数据存在问题。官方在Xtrabackup 8.0.14版本(基于MySQL 8.0.21)对该问题进行了修复，修复方法是redo备份线程，解析redo log时若发现该操作是undo log的truncate操作，则会备份失败。遗憾的是，该修复并没有完全解决问题，在以下两种场景中，社区版本的Xtrabackup仍可能会发生恢复出来的数据存在不一致的现象：

MySQL版本低于MySQL 8.0.21;
用户在备份过程中，自己创建了新的undo tablespace。
解决办法：在备份期间关闭undo tablespace的truncate操作，并禁止用户创建undo tablespace， 能够有效地防止备份数据恢复出来不一致的问题；另外华为云Xtrabackup对这个问题进行了进一步的修复，可以有效地防止此类现象发生。

3.加载表空间阶段
问题现象1：Xtrabackup报错：Too many open files
原因：操作系统允许同时打开的文件数量是有限的，Xtrabackup在load tablespace阶段会同时打开所有的表文件，如果Xtrabackup打开的表的个数超过了该限制，则会备份失败。

解决办法：调大操作系统，允许同时打开最大文件数的配置，或者使用 lock-ddl 参数(阻塞实例上新的DDL操作)。

问题现象2：rename table导致备份失败，错误信息如下：
“Trying to add tablespace 'xxxx' with id xxx to the tablespace memory cache, but tablespace xxxx already exists in the cache!;”

原因：在Xtrabackup打开表空间的全过程是没有加锁的，如果发生了rename table有概率会发生重复加载相同的表空间，此时Xtrabackup会检测到重复的tablespace id，因此备份失败。

解决办法：一般来说，加载表空间是一个很快的操作，rename table并不是一个很频繁的操作，这种情况重试即可(Percona Xtrabackup 2.4.x仅支持单线程加载表空间，华为云Xtrabackup支持多线程加载表空间)。

4.备份innodb表阶段
问题现象：innodb表数据文件损坏，备份失败，错误信息如下：
“xtrabackup: Database page corruption detected at page xxxx, retrying.”

原因：Xtrabackup在备份innodb表数据文件时，会检查每个页面的checksum，如果发现checksum不对，则备份失败，这时说明MySQL实例的数据已经发生了损坏(例如磁盘静默错误)。

解决办法：需要通过恢复前一次的备份数据或者其他的办法将数据进行修复之后，备份才能成功，在后续的文章中，我们也会详细介绍数据修复办法。