上一篇文章中我们写了使用XtraBackup备份mysql数据库，他的备份速度也是比较快。

但是问题来了，我们的系统在5月初，刚刚结束愉快的劳动节。就开始较大频率卡顿，开始是部分功能开始卡顿，没过几天，整个系统卡顿严重。几乎不能正常使用了，已经很严重影响了我们的正常业务操作了。

此时我们做了几个处理，优化代码，优化部分慢查询，升级服务器，升级数据库版本。本文主要讲述的是在把数据库从5.7升级到8.0之后xtraBackup无法正常备份后的替代备份方案，具体的系统优化流程后面我再写下来。

在数据库升级过后重新配置了数据库备份的脚本，同样通过XtraBackup进行备份数据库。但是当我过了几天后去检查数据库备份情况，发现并没有正常备份数据库。

经过检查后发现未正常备份的原因是xtraBackup进行备份数据库的命令中需要去读取mysql数据库的配置文件，而我们采用docker的形式部署了mysql8.0。所以我分析是以下几个问题导致无法进行正常备份：

无法正确读取数据库配置文件

我使用的xtraBackup2.4不支持mysql8.0及以上的数据库备份

使用最新版本的XtraBackup进行尝试备份后也无法正常备份，我暂时放弃了他！！我还会来的，毕竟XtraBackup还是比较好用的！

image

写了这么多终于到正文了。

对比及尝试了几个备份工具后，选择使用mydumper进行逻辑备份。mydumper与mysqldump原理比较类似，都是通过查询数据库后将相关表结构及数据以sql的形式保存下来。但是mydumper有以下几个特点：

多线程备份

c语言编写，性能比较优秀

备份速度也比较快，我们数据库在64线程耗时15分钟左右

输出管理方便，每个表一个sql文件，可单独恢复数据表

二、如何安装

三、如何备份数据库

mydumper同样使用命令行进行数据库备份，我采用的备份方式是写好脚本后通过服务器自带的定时任务进行数据库备份。

备份语法：

mydumper -u 用户 -p 密码 -P 端口 -h 地址 -B 数据库 -o 备份地址 -v 日志级别 -t 线程数

eg

mydumper -u copy -p pwd -P 33066 -h 192.168.1.214 -B test -o /home/data/eplusdb/backup_eplus$(date +%Y%m%d) -v 3 -t 64

参数详解：

-B, --database 要备份的数据库，不指定则备份所有库

-T, --tables-list 需要备份的表，名字用逗号隔开

-o, --outputdir 备份文件输出的目录

-s, --statement-size 生成的insert语句的字节数，默认1000000

-r, --rows 将表按行分块时，指定的块行数，指定这个选项会关闭

-F, --chunk-filesize 将表按大小分块时，指定的块大小，单位是 MB

-c, --compress 压缩输出文件

-e, --build-empty-files 如果表数据是空，还是产生一个空文件(默认无数据则只有表结构文件)

-x, --regex 是同正则表达式匹配 'db.table'

-i, --ignore-engines 忽略的存储引擎，用都厚分割

-m, --no-schemas 不备份表结构

-k, --no-locks 不使用临时共享只读锁，使用这个选项会造成数据不一致

--less-locking 减少对InnoDB表的锁施加时间(这种模式的机制下文详解)

-l, --long-query-guard 设定阻塞备份的长查询超时时间，单位是秒，默认是60秒(超时后默认mydumper将会退出)

--kill-long-queries 杀掉长查询 (不退出)

-b, --binlogs 导出binlog

-D, --daemon 启用守护进程模式，守护进程模式以某个间隔不间断对数据库进行备份

-I, --snapshot-interval dump快照间隔时间，默认60s，需要在daemon模式下

-L, --logfile 使用的日志文件名(mydumper所产生的日志), 默认使用标准输出

--tz-utc 跨时区是使用的选项

--skip-tz-utc 同上

--use-savepoints 使用savepoints来减少采集metadata所造成的锁时间，需要 SUPER 权限

-h, --host 连接的主机名

-u, --user 备份所使用的用户

-p, --password 密码

-P, --port 端口

-S, --socket 使用socket通信时的socket文件

-t, --threads 开启的备份线程数，默认是4

-C, --compress-protocol 压缩与mysql通信的数据

-V, --version 显示版本号

-v, --verbose 输出信息模式, 0 = silent, 1 = errors, 2 = warnings, 3 = info, 默认为 2

四、如何还原数据库

数据库还原使用的关键字是：myloader

还原语法：

myloader -u 用户 -p 密码 -h 地址 -P 端口 -B 数据库 -d 还原目录 -v 日志级别 -t 线程数

eg：

myloader -u copy -p 123456 -h 192.168.1.214 -P 33066 -B test -d /home/data/backup20200718 -v 3 -t 82

参数详解：

-d, --directory 备份文件的文件夹

-q, --queries-per-transaction 每次事物执行的查询数量，默认是1000

-o, --overwrite-tables 如果要恢复的表存在，则先drop掉该表，使用该参数，需要备份时候要备份表结构

-B, --database 需要还原的数据库

-e, --enable-binlog 启用还原数据的二进制日志

-h, --host 主机

-u, --user 还原的用户

-p, --password 密码

-P, --port 端口

-S, --socket socket文件

-t, --threads 还原所使用的线程数，默认是4

-C, --compress-protocol 压缩协议

-V, --version 显示版本

-v, --verbose 输出模式, 0 = silent, 1 = errors, 2 = warnings, 3 = info, 默认为2

五、总结

使用mydumper进行数据库备份过程中，整库备份比较快，但是说是话整库恢复就比较慢了。我定义了同样的64个线程数进行数据库备份，但是我使用64线程进行数据库恢复时，差不多花了5个小时，特别是数据量较大的表恢复特别慢。我也还在调研有没有更适合更快捷的备份工具，如果大家有比较号的备份工具的请多多推荐！！