乐趣区

关于数据库:想了解Xtrabackup备份原理和常见问题分析看这篇就够了

jiezi

摘要：本文来自华为云 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 元起，助力企业无忧上云，欢送大家前来体验

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

退出移动版