xtrabackup是Percona公司的一款用于MySQL在线备份的工具，支持在线备份，全量备份和增量备份，单库单表备份。
mydumper能够良好支持多线程工作，在处理速度方面快于传统的mysqldump大约10倍的速度。其特征之一是在处理过程中需要对列表加以锁定，如果在业务高峰时段执行备份工作，可能会引起DML阻塞。
本文侧重于介绍在xtrabackup安装过程中遇到的问题和解决方案。
CentOS6 64位系统，MySQL5.7.16中有几张200G左右的单表需要备份下来后存储起来，并且释放空间，希望尽量压缩时间成本。这时候想到了两种方法：
1.mydumper工具，单表备份，下载地址：MySQL Data Dumper in Launchpad
2.xtrabackup工具，单表备份，下载地址：Percona Software downloads for databases
1.xtrabackup工具使用
单表备份：
**备份：** 方法一：innobackupex --include='^database[.]table' /path/to/backup --user=backup --password=backup 方法二：innobackupex --databases="database.table" /path/to/backup --user=backup --password=backup 方法三： echo 'database.table' >/tmp/tables.txt innobackupex --tables-file=/tmp/tables.txt /path/to/backup --user=backup --password=backup复制
2.mydumper工具使用
单表备份： mydumper -u dbadmin -p 123456 -h 127.0.0.1 -P 3410 -B databse -T tablename -v 3 -t 8 -F 2500 -o /data/backup/mysql/ 单表恢复： myloader -u root -p 123456 -h 127.0.0.1 -B databse -T tablename -v 3 -t 8 -e -d /data/backup/mysql/ #####注意：在单表备份时候，我是在从库做的备份，此时主从复制进程是一个长会话，会造成备份失败，可以考虑先stop slave一段时间，备份完成后再次打开主从复制。复制
-v 表示输出信息模式0 = silent, 1 = errors, 2 = warnings, 3= info, 默认为2。
-t 开启的备份线程数，默认是4。
-F 将表按大小分块时，指定的块大小，单位是 MB
-e 如果表数据是空，还是产生一个空文件（默认无数据则只有表结构文件）
详细了解mydumper工具，可以参考mydumper备份原理和使用方法_sofia1217的专栏-CSDN博客
测试结果
在单表256G的单表进行备份测试，mydumper性能为1小时10G，速度很慢。xtrabackup工具40分钟将256G数据备份完成。在这个业务场景下，显然xtrabackup工具更加表现优异。
安装xtrabackup工具遇到的问题之 conflicts with file
mysql-community-server-8.0.22-1.el7.x86_64 conflicts with file from package mysql-community-server-5.7.19-1.el7.x86_64
此时查看rpm -qa｜grep mysql
缺失mysql-lib 的5.7.16版本，只有mysql-lib的8.0.22的版本。
解决办法
安装对应的版本的mysql-community-libs：
可以在此网站上找到自己对应的版本并下载： https://repo.mysql.com/yum/mysql-5.7-community/el/7/x86_64/
rpm -ivh mysql-community-libs-compat-5.7.19-1.el7.x86_64.rpm
再次安装xtrabackup，即成功。
单表备份过程中的log scans未发生变化，持续30分钟左右
在使用xtrabackup工具进行备份，在从库执行。此时屏幕输出的信息中大量出现 log scanned up to （865855709053），并且括号中的序列一直未发生变化，是同一串数字。
此时通过 du -h命令查看备份目录也始终保持0的大小。
此时通过 ls -l -h命令查看备份目录中的的table.ibd文件，可以看到表在不断变大。
但是log scanned up to （865855709053）始终不变，此时出现这个情况可能是两个原因：
1.数据库卡住
2.数据库没有任何业务写入。
此时进入数据库，测试创建一张表并且删除，能够执行成功。
此时log scanned up to （865855709053）发生改变。
