技术分享 | 满足多场景需求的 MySQL 物理备份实践
1问题背景
在 MySQL 日常运维中，备份是一个必不可少的环节，最常用的一般则是 Percona XtraBackup 工具。
图片来源：在使用 Percona XtraBackup 工具对 MySQL 数据库备份恢复时，我们通常会考虑以下因素：
备份恢复数据所需要的时间。
备份期间对主库服务器负载的影响。
备份集文件的大小。
分别对从这三个点进行展开描述：
1. 备份恢复数据所需要的时间
相同数据量情况下，通常我们希望 备份恢复所需要的时长越短越好，为什么这么说呢？
一方面，对于日常备份，一般会选择业务低峰期进行，如果备份占用的时长过长，可能会影响正常业务；另一方面，如果没有历史可用备份集，需要紧急临时备份进行数据恢复时候，这时候肯定是希望能够进行尽快的能够恢复，毕竟如果是重要业务，可能耽搁越久，每分每秒都给企业带来巨大损失；另外，如果 Redo 日志设置不合理，可能好不容易备份成功了，在恢复的时候发现 Redo 日志已经被覆盖，此时内心估计也会很郁闷吧。还有一些《Percona XtraBackup工具备份恢复过程中可能遇到的其他的问题》可参考。
2. 备份期间对主库服务器负载的影响
备份的本质是为了应对数据库数据误操作或者数据损坏等突发情况。
如果因为备份导致主服务器负载高，进而诱发数据库服务出现异常，那就得不偿失了。因为数据库备份期间会涉及加锁操作和写文件操作，因此是有可能阻塞业务的，并占用一部分磁盘 IO。
3. 备份集文件的大小
在金融行业，对备份集保留时间有严格的要求。
对于数据量越大的实例，其备份集自然也会越大。长期以往积累的备份集文件会需要很多额外的空间进行存储，例如：保留一个月的备份集，每份备份集大小为 200G，仅仅一个实例来说已经会占用不小的硬盘空间，而大企业往往会有成千上万个实例。如果单份备份集能从 200G 降到 150G 或者更小，总体上那也会节省很多空间，也能为企业节省成本支出。
对于第 2 点，可以通过设置
--kill-long-queries-timeout
，--ftwrl-wait-timeout
，--ftwrl-wait-threshold
，--use-memory
，--throttle
等参数设置对长查询，内存，IO 方面进行合理的限制，或者选择对从实例进行备份（如果主从不同步，则备份为无效备份，可以对主从同步进行监控，同步正常情况下在从库进行备份）。
本篇仅考虑备份时间和备份集文件大小方面。 结合实践，从以下三个维度前后的备份工具区别进行展开：
本地备份
跨机器远程备份
Percona XtraBackup 8.0
2本地测试环境
从官网下载对应的二进制包，对于 Percona XtraBackup 工具，如果缺少部分依赖包可能导致无法正常备份。建议从官网下载地址[1] 进行对应下载。另外，不同版本的 Percona XtraBackup 和 MySQL 可能存在兼容性，以官网信息为准。
3测试流程
在 Percona XtraBackup 8.0 之前，Percona XtraBackup 工具中，xtrabackup
是备份的主程序，在 Percona XtraBackup 8.0 之前，除了 xtrabackup
文件，还有 innobackupex
文件，不过它只是 xtrabackup
的一个软链。
[root@localhost bin]# cd /root/backup/percona-xtrabackup-2.4.26-Linux-x86_64.glibc2.12/bin/<br>[root@localhost bin]# ll<br>lrwxrwxrwx 1 root root 10 May 3 2022 innobackupex -> xtrabackup<br>-rwxr-xr-x 1 root root 9963231 May 3 2022 xbcloud<br>-rwxr-xr-x 1 root root 3020 May 3 2022 xbcloud_osenv<br>-rwxr-xr-x 1 root root 5158940 May 3 2022 xbcrypt<br>-rwxr-xr-x 1 root root 5229968 May 3 2022 xbstream<br>-rwxr-xr-x 1 root root 200906741 May 3 2022 xtrabackup<br>
