本文来自华为云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进行备份，进程如下图所示：

华为云带你探秘Xtrabackup备份原理和常见问题分析
图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的备份进程如下：

华为云带你探秘Xtrabackup备份原理和常见问题分析

图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元起，助力企业无忧上云，欢迎我们前来体会>>activity.huaweicloud.com/dbs_Promoti…