MySQL如何选择合适的备份策略和备份工具

MySQL如何选择合适的备份策略和备份工具

数据库备份的重要性毋庸置疑，可以说，它是数据安全的最后一道防线。鉴于此，对于备份，我们通常会做以下要求：

多地部署

对于核心数据库，我们通常有两地三中心的部署要求。对于备份来说，也是如此。

一个备份应该有多个副本，每个副本存储在不同区域。

多介质部署

一个备份的多个副本应存储在不同介质上，如磁盘和磁带，防止单一介质失效。

定期检查备份的有效性

备份只是在做正确的事情，有没有把事情做对，还得依靠备份的有效性检查。

前两项，在条件允许的情况下，建议做。第三项必须做。

接下来，我们聊聊备份的相关话题，主要包括以下五方面的内容：

备份的常见分类。MySQL中的备份工具。mysqlbackup与mysqldump的备份恢复速度对比。如何检测备份的有效性。RTO和RPO 。

一、备份的常见分类

1、物理备份 VS 逻辑备份

1）物理备份

顾名思义，就是备份物理文件。其优缺点如下：

① 优点

备份、恢复速度快。尤其是恢复速度，直接关系着数据库服务的RTO。无需实例在线。在实例关闭的情况下，可直接拷贝文件，不用担心备份的一致性。关闭实例进行备份，也称之为 “冷备” 。

② 缺点

备份文件大。恢复时，对平台、操作系统、MySQL版本有要求，必须一致或兼容。只能在本地发起备份。因为是拷贝物理文件，即使文件中存在很多“空洞”（大量DELETE导致），也无法通过恢复来收缩 。对表的存储引擎有要求，无法备份MEMORY表。

2）逻辑备份

备份表的逻辑记录。其优缺点如下：

① 优点

可移植性强。恢复时，对平台、操作系统、MySQL版本无要求。灵活。尤其是在恢复时，可只恢复一个库或一张表。对表的存储引擎没有要求，任何类型的表都可备份。备份文件较小。可远程发起备份。恢复后，能有效收缩空间。

② 缺点

备份、恢复速度慢。实际上，单论备份速度，多线程备份其实也不慢。但恢复速度呢，即使是多线程恢复，也很慢。备份会"污染"Buffer Pool。业务热点数据会被备份数据驱逐出Buffer Pool。

2、离线备份 VS 在线备份

离线备份，又可称之为 "冷备"，即实例关闭的情况下进行的备份。此时，只能进行物理备份，即全量拷贝物理文件。

在线备份，又可称之为 "热备"，即实例运行过程中进行的备份。此时，既可进行物理备份，又可进行逻辑备份。

因对业务侵入较小，线上一般使用在线备份。

3、全量备份 VS 增量备份

全量备份，即备份整个实例的全量数据。

增量备份，即只备份上次备份以来，那些发生了"变化"的数据。

通常来说，基于物理备份来实现增量备份较为简单，以MySQL为例，只需判断数据页的LSN是否发生了变化。

而对于逻辑备份，就很难实现，如常见的基于某个时间字段来进行增量备份，但其实，很难保证某个时间段之前的数据不被修改或删除。

二、MySQL中的备份工具

1、物理备份

物理备份相关的工具有：

1）XtraBackup

Percona公司开源的备份工具，适用于MySQL、MariaDB、Percona Server。

XtraBackup目前维护的大版本有两个：

XtraBackup 2.4，适用于MySQL 5.6和5.7。XtraBackup 8.0。适用于 MySQL 8.0。

之所以要维护两个版本，是因为MySQL 8.0中的redo log和数据字典的格式发生了变化。

2）mysqlbackup

MySQL企业级备份工具（ MySQL Enterprise Backup ），适用于MySQL企业版。

3）Clone Plugin

MySQL 8.0.17引入的克隆插件。初衷是为了方便Group Replication添加新的节点。有了Clone Plugin，我们也能很方便的搭建一个从库，无需借助其它备份工具。

三者的实现原理基本相同，都是在备份的过程中，拷贝物理文件和redo log ，最后，再利用InnoDB Crash Recovery，将物理文件恢复到备份结束时的一致性状态。

2、逻辑备份

逻辑备份相关的工具有：

1）mysqldump

MySQL安装包自带的备份工具，单线程备份。

2）mydumper

由Facebook、SkySQL、***和Percona开发人员维护的一个多线程备份工具，可实现行级别的并行备份。

3）mysqlpump

MySQL 5.7引入的备份工具，可实现表级别的并行备份。

4）MySQL Shell

MySQL Shell 8.0.21引入了一个工具-util.dumpInstance()，可实现行级别的并行备份。

这个工具对备份实例和恢复实例的版本有要求：备份实例 >= 5.6，恢复实例 >= 5.7。

5）SELECT ... INTO OUTFILE

SQL命令，可将表记录直接导出到文件中。

下面说说这几个工具的异同点：

从实现原理来看，mysqldump、 mydumper、mysqlpump、 MySQL Shell可归为一类，本质上都是通过SELECT * FROM TABLE的方式备份数据，只不过在此基础上，通过全局读锁 + REPEATABLE READ事务隔离级别，实现了数据库的一致性备份。SELECT ... INTO OUTFILE 充其量只是一个命令，算不上工具，更不用说数据库的一致性备份。从导出的内容来看，mysqldump、mydumper、mysqlpump 会以INSERT语句的形式保存备份结果，如：

INSERT INTO `t1` VALUES (1,'aaa'),(2,'bbb'),(3,'ccc');

而 MySQL Shell和SELECT ... INTO OUTFILE 是以CSV格式的形式保存备份结果，如，

1 aaa2 bbb3 ccc

在恢复，各个工具对应的恢复工具也不一样。具体来说，

mysqldump、mysqlpump对应的恢复工具是mysql客户端，所以是单线程恢复。

mydumper对应的恢复工具是myloader，支持多线程恢复。

util.dumpInstance()对应的恢复工具是util.loadDump()，该工具实际调用的是LOAD DATA LOCAL INFILE命令，支持多线程恢复。

SELECT ... INTO OUTFILE对应的恢复命令是LOAD DATA。

三、mysqlbackup VS mysqldump

下面是MySQL官方提供的一组数据，对比了mysqlbackup和mysqldump备份恢复时间。

第一张图比较的是备份时间，mysqldump是mysqlbackup的49倍。

第二张图比较的是恢复时间，mysqldump是mysqlbackup的80倍。

借此，我们也能看到逻辑备份工具相对于物理备份工具在备份、还原速度上的差距。

不过可惜的是，这里没有测试mydumper。

毕竟，针对数据量较大的实例，如果一定要使用逻辑备份，大家一般倾向于使用mydumper，而不是mysqldump。

四、如何检测备份的有效性

为什么要检测备份的有效性，原因主要有两个：

验证整个备份环节的可靠性。包括备份参数是否完备，备份集是否有效，备份介质是否损坏等。通过检查备份的有效性，搭建一套完整的自动化恢复体系。

很多时候，影响数据库恢复时间的并不是备份集太老，而是手动恢复过程中，因为命令、环境、流程的不熟悉，所带来的额外耗时。

如何检测备份的有效性，常用的方法有三个：

基于备份恢复实例，看实例能否起来。并在此基础上，进行随机查询。

这种检测方法最简单。

一般来说，实例能起来，且随机查询也没问题，就意味着这个备份集是可用的。

但备份集可用，并不意味着这个备份集能满足我们的需求，譬如常见的，搭建从库。

而且一些常见的问题，如备份中断、参数没指定准确，也无法通过这种方式检测出来。

在1的基础上，建立复制。

如果从库在追主库的过程中，没有报错，大概率意味着主从数据是一致的。当然，也只是大概率，并不是100%。

在2的基础上，利用pt-table-checksum检查主从数据的一致性。

如果检查结果没问题，则意味着主从数据是一致的，也就间接证明了备份的有效性。

但因为pt-table-checksum在运行的过程中，会在chunk级别对表加S锁，对更新频繁的业务，还是有一定的影响。

一般来说，线上使用方法2足矣。

方法3，因为要检查主从数据的一致性，耗时相对较久，如果要检测的备份集很多，反而会影响检测的效率。

五、RTO 和 RPO

衡量一个数据中心的容灾能力时，有两个常用的指标：

RTO：Recovery Time Objective，恢复时间目标。

指的是灾难发生后，必须在这个时间内恢复数据。

在恢复数据的这段时间内，服务是不可用的，所以RTO也是服务可允许的最大不可用时间。如果我们要求服务的最大不可用时间是30分钟，那么RTO就是30分钟。

RTO 越小，代表容灾系统的恢复能力越强。

RPO：Recovery Point Objective，数据恢复点目标。

指的是灾难发生后，数据可以恢复到的时间点。

譬如，我有一个系统，每天0点进行一次全备。当系统出现故障后，会基于上一次的备份来恢复。如果系统在凌晨3点出现故障，我们会丢失3个小时的数据。极端情况下，系统在23:59出现故障，我们会丢失24个小时的数据。这里的24小时就是这个系统的RPO 。

RPO越小，代表系统越能保证数据的完整性。

RTO、RPO与灾难在时间轴上的关系如下图所示：

可以看到，RPO针对的是数据丢失，RTO针对的是服务宕机时间，两者之间没有必然的联系。

最理想的情况是RTO和RPO都为0，这就意味着当灾难发生时，系统会立即恢复，而且数据不会丢失。当然，RTO、RPO越小，需要投入的成本也越高。

具体到MySQL中，为了降低RTO和RPO，我们可以从以下几个方面着手：

1）RTO

增加备份频率，缩短备份周期。选择物理备份，而不是逻辑备份。添加延迟从库。恢复流程的自动化。

2）RPO

增加备份频率，缩短备份周期。搭建Binlog Server备份Binlog。当出现故障时，我们可以基于备份和Binlog做基于时间点的恢复。添加延迟从库。

六、总结

从RTO的角度出发，应尽量选择物理备份，而不是逻辑备份。如果要使用逻辑备份，应尽量选择多线程备份工具和多线程恢复工具。

从RPO的角度出发，应尽量增加备份频率，缩短备份周期。

但 every coin has two sides，使用物理备份或者增加备份频率，无疑会增加存储成本。

所以，在确定备份策略和选择备份工具时，应从业务的RTO和RPO出发，结合存储成本综合考虑。

大多数公司会采取一个统一的备份策略，如一天一个全备。虽然灾难情况很少出现，开发和DBA童鞋也应充分理解到这里面的风险，并制定相应的预案及业务兜底方案。

另外，对于线上核心业务，如果只有备份，还是很难有效降低数据库服务的RTO和RPO，建议部署延迟从库。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。