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

database

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

  • 多地部署

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

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

  • 多介质部署

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

  • 定期检查备份的有效性

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

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

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

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

备份的常见分类

物理备份 VS 逻辑备份

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

优点:

  • 备份、恢复速度快。

    尤其是恢复速度,直接关系着数据库服务的RTO。

  • 无需实例在线。

    在实例关闭的情况下,可直接拷贝文件,不用担心备份的一致性。

    关闭实例进行备份,也称之为 “冷备” 。

缺点:

  • 备份文件大。

  • 恢复时,对平台、操作系统、MySQL版本有要求,必须一致或兼容。

  • 只能在本地发起备份。

  • 因为是拷贝物理文件,即使文件中存在很多“空洞”(大量DELETE导致),也无法通过恢复来收缩 。

  • 对表的存储引擎有要求,无法备份MEMORY表。

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

优点:

  • 可移植性强。恢复时,对平台、操作系统、MySQL版本无要求。

  • 灵活。尤其是在恢复时,可只恢复一个库或一张表。

  • 对表的存储引擎没有要求,任何类型的表都可备份。

  • 备份文件较小。

  • 可远程发起备份。

  • 恢复后,能有效收缩空间。

缺点:

  • 备份、恢复速度慢。

    实际上,单论备份速度,多线程备份其实也不慢。但恢复速度呢,即使是多线程恢复,也很慢。

  • 备份会"污染"Buffer Pool。

    业务热点数据会被备份数据驱逐出Buffer Pool 。

离线备份 VS 在线备份

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

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

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

全量备份 VS 增量备份

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

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

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

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

MySQL中的备份工具

物理备份

物理备份相关的工具有:

  • XtraBackup

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

    https://www.percona.com/software/mysql-database/percona-xtrabackup

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

    1. XtraBackup 2.4,适用于MySQL 5.6和5.7。

    2. XtraBackup 8.0。适用于 MySQL 8.0。

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

  • mysqlbackup

    MySQL企业级备份工具( MySQL Enterprise Backup ),适用于MySQL企业版。

    https://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/mysqlbackup.html

  • Clone Plugin

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

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

逻辑备份

逻辑备份相关的工具有:

  • mysqldump

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

  • mydumper

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

  • https://github.com/maxbube/mydumper

  • mysqlpump

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

  • MySQL Shell

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

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

  • SELECT ... INTO OUTFILE

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

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

  1. 从实现原理来看,mysqldump、 mydumper、mysqlpump、 MySQL Shell可归为一类,本质上都是通过SELECT * FROM TABLE的方式备份数据,只不过在此基础上,通过全局读锁 + REPEATABLE READ事务隔离级别,实现了数据库的一致性备份。

  2. SELECT ... INTO OUTFILE 充其量只是一个命令,算不上工具,更不用说数据库的一致性备份。

  3. 从导出的内容来看,mysqldump、mydumper、mysqlpump 会以INSERT语句的形式保存备份结果,如,

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

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

    1       aaa
    2       bbb
    3       ccc

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

    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. 验证整个备份环节的可靠性。

    包括备份参数是否完备,备份集是否有效,备份介质是否损坏等。

  2. 通过检查备份的有效性,搭建一套完整的自动化恢复体系。

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

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

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

    这种检测方法最简单。

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

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

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

  2. 在1的基础上,建立复制。

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

  3. 在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,我们可以从以下几个方面着手:

RTO

  1. 增加备份频率,缩短备份周期。

  2. 选择物理备份,而不是逻辑备份。

  3. 添加延迟从库。

  4. 恢复流程的自动化。

RPO

  1. 增加备份频率,缩短备份周期。

  2. 搭建Binlog Server备份Binlog。当出现故障时,我们可以基于备份和Binlog做基于时间点的恢复。

  3. 添加延迟从库。

总结

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

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

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

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

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

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

参考

[1] 关于RTO,你理解对了吗?

[2] 恢复时间目标 (RTO) 和恢复点目标 (RPO) 

[3] MySQL Enterprise Backup https://www.mysql.com/cn/products/enterprise/backup.html

以上是 MySQL中如何选择合适的备份策略和备份工具 的全部内容, 来源链接: utcz.com/z/536014.html

回到顶部