摘要：本文来自华为云MySQL研发团队，次要分享了MySQL备份工具Xtrabackup的备份过程、华为云数据库团队对其做的优化改良，以及在应用中可能遇到的问题与解决办法。

本文分享自华为云社区《华为云带你探秘Xtrabackup备份原理和常见问题剖析》，作者：GaussDB 数据库 。

本文来自华为云MySQL研发团队，次要分享了MySQL备份工具Xtrabackup的备份过程、华为云数据库团队对其做的优化改良，以及在应用中可能遇到的问题与解决办法。文章探讨的内容次要是针对华为云RDS for MySQL, 以及用户自建的社区版MySQL数据库，心愿有助于大家了解和应用Xtrabackup，当前面对Xtrabackup问题也更加从容。

一、Xtrabackup简介

Xtrabackup是Percona团队开发的用于MySQL数据库物理热备份的开源备份工具，具备备份速度快、反对备份数据压缩、主动校验备份数据、反对流式输入、备份过程中简直不影响业务等特点，是目前各个云厂商广泛应用的MySQL备份工具。

以后Xtrabackup存在两个版本：Xtrabackup 2.4.x与8.0.x，别离用于备份MySQL 5.x与MySQL 8.0.x 版本。上面咱们别离介绍 Xtrabackup如何备份MySQL社区版以及华为云上的Xtrabackup的备份原理

二、社区版MySQL的Xtrabackup备份

Xtrabackup是为Percona MySQL设计的，同时也反对对官网社区版本MySQL进行备份，过程如下图所示：

图1：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. 开释锁资源，备份完结。

须要留神的是，Xtrabackup 2.4.x与8.0.x在第7、8这两个步骤存在差别，这个差别有MySQL 8.0.x的起因，详情咱们在下文介绍。

三、华为云RDS for MySQL备份

在备份社区版MySQL实例时，Xtrabackup会对实例加全局读锁(FTWRL)，该锁对数据库的业务影响很大，重大时甚至会导致数据库“挂起”，这对客户来说是不可承受的。因而华为云MySQL团队对这个过程进行了优化，次要有两点：

  1. 对MySQL 5.x以及0.x减少了备份锁：LOCK TABLES FOR BACKUP
  2. 对MySQL 5.x新增了binlog锁：LOCK BINLOG FOR BACKUP

优化之后，华为云Xtrabackup对MySQL的备份过程如下：

图2 Xtrabackup备份华为云MySQL流程示意

与FTWRL锁相比，备份锁 LOCK TABLES FOR BACKUP对客户实例影响很小，其加锁过程简略，加锁期间innodb表的DML操作不受影响，然而非innodb表的所有的更新操作以及DDL操作依然是不容许的。

备份完所有的表文件后，Xtrabackup须要获取binlog GTID信息。

• 对于MySQL 5.x版本，Xtrabackup 2.4.x会执行 LOCK BINLOG FOR BACKUP 操作，对binlog加锁，而后获取GTID信息。
• 对于MySQL 8.0.x版本，华为云Xtrabackup 8.0.x沿用官网的一致性备份点查询方法。Xtrabackup查问log_status 时，MySQL服务器会别离对redo log, binlog等加轻量级锁，获取一致性备份点，这个过程是十分短暂的，对实例的运行简直没有影响。MySQL 8.0.x的备份一致性点，会通知咱们一致性的redo log LSN以及binlog的GTID；查问齐备份统一点后，Xtrabackup会备份最初一个binlog文件，用于复原时仲裁事务是否须要回滚；最初，redo log备份线程工作会在其读取到的redo log的LSN大于查问到的备份一致性点的redo log LSN处进行。

因为Xtrabackup 2.4.x与8.0.x在解决binlog时存在差别，复原过程也存在差别，咱们会在后续文章中具体论述。

四、常见问题与解决办法

华为云曾经应用Xtrabackup为公司简直所有的MySQL实例提供备份服务，在应用过程中，咱们踊跃与社区保持联系，向Percona社区报告应用过程中的一些问题，帮忙Xtrabackup向更好的方向演进。此外，对于发现的一些致命问题，若社区未能及时修复，华为云数据库团队会进行及时修复以保障备份数据的正确性。

上面是咱们总结在应用Xtrabackup备份过程各个阶段可能遇到的问题，剖析其起因以及对应的解决办法，

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仍可能会产生复原进去的数据存在不统一的景象：

  1. MySQL版本低于MySQL 8.0.21;
  2. 用户在备份过程中，本人创立了新的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实例的数据曾经产生了损坏(例如磁盘静默谬误)。

解决办法：须要通过复原前一次的备份数据或者其余的方法将数据进行修复之后，备份能力胜利，在后续的文章中，咱们也会具体介绍数据修复方法。

五、结语

本文次要比照介绍了Xtrabackup备份原理，备份社区版MySQL以及华为云对其的改良，并分享了Xtrabackup常见问题的排查与解决，后续咱们也会为大家带来更深刻的剖析，更实用的应用技巧，心愿对大家了解和应用Xtrabackup有帮忙。咱们也将继续为客户提供更好的数据库服务，并时刻守护客户的数据安全。

最初，通知大家一个好消息，云数据库MySQL包年19.9元起，助力企业无忧上云，欢送大家前来体验

点击关注，第一工夫理解华为云陈腐技术~