xtrabackup备份异常场景暂时梳理了以下8种场景，后续如果有新的再进行补充吧。

这种场景下一般日志中会有xtrabackup: Database page corruption detected at page xxxx, retrying等报错，这种情况是因为mysql的数据文件发生了损坏，而Xtrabackup在备份innodb表数据文件时，会检查每个页面的checksum，如果checksum值不对，则说明页已经被损坏，此时备份会失败，此时先要修复数据，可以通过myisamchk工具，percona-data-recovery-tool工具，或者设置innodb_force_recovery参数导出数据等几种方法尝试进行恢复后再进行备份。

2.redo日志覆盖场景:

这种场景下一般日志中会有如下报错：xtrabackup: error: log block numbers mismatch:

xtrabackup: error: expected log block no. 586990567, but got no. 587187167 from the log file.

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.这种情况一般是由于业务写入较快导致redo log写入速度很快或者redo log参数设置过小，redo log文件是循环写的，如果xtrabackup的redo log备份线程的速度低于redo log写入速度，导致新写入的日志覆盖之前写入但是还未备份的日志。从而导致备份报错，这种场景有三种解决方法，第一，先尝试调整备份策略，在业务低峰期进行备份。第二，调整redo log相关参数，涉及参数有innodb_log_file_size(设定单个redo日志文件大小),innodb_log_files_in_group(redo日志)，修改这两个参数需要重启mysql服务。第三，如果前面两者不生效，需要从业务侧进行调整写入策略。

3.获取mdl锁失败:

这种场景的现象一般是xtrabackup在启动后卡住并且redo log备份线程未启动。原因是xtrabackup在起始阶段兼容性检查表的引擎信息时候会查询information_schema.table插件表，查询对应的表时，需要获取对应表的mdl(元数据锁)，如果此时有长时间的dml或者ddl语句或者mdl死锁情况发生，可能会导致查询一直卡住，此时如果只是sql语句导致的等待，则无需处理，如果是存在mdl死锁，则需要解决死锁问题。

4.备份期间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.导致备份失败的原因是备份期间发生了不记录redo log的ddl操作，这操作可能会导致数据不一致问题，因此备份失败，例如备份过程中进行索引创建操作，解决方法是在备份时添加lock-ddl,lock-ddl-timeout,lock-ddl-per-table等参数。

5.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，从而备份失败。这种情况发生的可能性较小，即使遇到了重新备份即可。

6.打开文件个数限制报错:

这种场景一般会有如下报错:InnoDB: Operating system error number 24 in a file operation.

InnoDB: Error number 24 means ‘Too many open files’ InnoDB: Some operating system error numbers are described at ,导致这种报错的原因是xtrabackup在加载表空间时会同时打开所有表文件，如果实例的表个数较多，可能会触发该报错，解决方法是调整操作系统相关参数或者备份时使用lock-ddl,lock-ddl-timeout,lock-ddl-per-table等参数。

调整方法参考:

在/etc/security/limits.conf文件中设置,${username}替换为实际的操作系统用户即可。

${username} hard nofile 65535

${username} soft nofile 65535

${username} hard nproc 65535

${username} soft nproc 65535

7.io_setup() failed报错:

这种场景一般会有如下报错InnoDB: Warning: io_setup() failed with EAGAIN. Will make 5 attempts before giving up.造成该报错的原因是mysql启动时默认启用innodb_use_native_aio，使用异步IO操作，如果此时需要的aio slot大于系统设定的值，则会报上面的错，可以通过strace命令查看io_setup调用情况，可参考命令：

strace -fe trace=io_setup /path/to/mysqld --defaults-file=/etc/my.cnf --daemonize 2>&1 |grep io_setup

解决该问题方法是调整值，可通过编辑/etc/sysctl.conf文件修改fs.aio-max-nr参数值后执行sysctl -p命令刷新或者直接执行sysctl fs.aio-max-nr=修改后的值，注意修改后的值应大于实例的fs.aio-nr值。

8.truncate table/partition操作:

这种场景一般可以在备份期间避免该操作或者添加lock-ddl,lock-ddl-timeout,lock-ddl-per-table等参数。

好几周没更新日记了，最近在看xtrabackup备份这一块的知识点，一方面是感觉对xtrabackup备份流程这一块还有很多困惑，这几天也在向认识的一些大佬在请教。另外一方面，最近自己在新学习mongo数据库的课程。之前对mongo没咋接触，学习起来还是要花些精力的。就一直这么拖着了。哈哈，初学了一遍mongo,感觉mongo跟mysql,redis相比，也有很多亮点，等二刷课程的时候再献上笔记吧，哈哈，偏题了，回到主题吧，本次笔记主要是梳理了下xtrabackup的版本问题，8.0前后备份的原理差异，以及我和认识的一些小伙伴们踩到的一些坑，希望对你有帮助。也不枉费大早上跑起来写昨晚没搞完的笔记了。