如何为MySQL选择合适的备份策略和备份工具数据库备份的重要性毋庸置疑。可以说是数据安全的最后一道防线。鉴于此，我们通常对备份有如下需求：多地部署对于核心数据库，我们通常有两地三中心的部署需求。备份也是如此。备份应该有多个副本，每个副本存储在不同的区域。多介质部署一个备份的多个副本应该存储在不同的介质上，例如磁盘和磁带，以防止单一介质失效。定期检查备份的有效性。备份只是在做正确的事情。您是否正确地做事取决于备份的有效性。有条件的推荐前两项。第三个一定要做。接下来说一下备份相关的话题，主要包括以下五个方面：备份的常见分类。MySQL中的备份工具。mysqlbackup与mysqldump备份恢复速度对比。如何检查备份的有效性。RTO和RPO。一、备份的常见分类1、物理备份VS逻辑备份1）物理备份顾名思义就是对物理文件进行备份。其优缺点如下：①优点备份和恢复速度快。特别是恢复速度直接关系到数据库服务的RTO。无需实例在线。当实例关闭时，可以直接复制文件，无需担心备份的一致性。关闭实例进行备份，也称为“冷备用”。②缺点备份文件较大。恢复时对平台、操作系统、MySQL版本都有要求，必须一致或兼容。备份只能在本地启动。因为复制的是物理文件，即使文件有很多“洞”（大量DELETE造成），也无法通过recovery缩小。对表的存储引擎有要求，不能备份MEMORY表。2)逻辑备份备份表的逻辑记录。其优缺点如下：①便携性强。恢复时对平台、操作系统、MySQL版本没有要求。灵活的。尤其是恢复的时候，只能恢复一个库或者一张表。对表的存储引擎没有要求，可以备份任何类型的表。备份文件较小。可以远程启动备份。回收后，可以有效缩小空间。②缺点备份和恢复速度慢。其实单从备份速度来说，多线程备份其实并不慢。但是恢复速度，即使是多线程恢复，也很慢。备份“污染”了缓冲池。业务热点数据将被备份数据从BufferPool中逐出。2.离线备份VS在线备份离线备份，又称“冷备份”，是指在实例关闭时进行的备份。此时只能进行物理备份，即物理文件全量复制。在线备份，也称为“热备份”，是指在实例运行时进行的备份。此时，既可以进行物理备份，也可以进行逻辑备份。由于对业务的侵入性小，一般采用在线备份方式。3、全量备份VS增量备份全量备份就是备份整个实例的全部数据。增量备份，即只备份自上次备份后“改变”的数据。一般来说，基于物理备份来实现增量备份是比较简单的。以MySQL为例，只需要判断数据页的LSN是否发生变化即可。对于逻辑备份，实现起来比较困难，比如常见的基于某个时间字段的增量备份，但实际上很难保证某个时间段之前的数据不被修改或删除。二、MySQL中的备份工具1、物理备份与物理备份相关的工具有：1）XtraBackupPercona的开源备份工具，适用于MySQL、MariaDB、PerconaServer。https://www.percona.com/software/mysql-database/percona-xtrabackupXtraBackup目前维护两个主要版本：XtraBackup2.4，适用于MySQL5.6和5.7。XtraBackup8.0.适用于MySQL8.0。之所以保持两个版本是因为MySQL8.0中redolog和数据字典的格式发生了变化。2）mysqlbackupMySQL企业级备份工具（MySQLEnterpriseBackup），适用于MySQL企业版。https://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/mysqlbackup.html3)ClonePluginMySQL8.0.17引入的克隆插件。初衷是为了方便GroupReplication增加新的节点。通过ClonePlugin，我们也可以在不使用其他备份工具的情况下，轻松搭建从库。三者的实现原理基本相同。它们都是在备份过程中复制物理文件和重做日志，最后使用InnoDBCrashRecovery将物理文件恢复到备份结束时的一致状态。2、逻辑备份逻辑备份相关的工具包括：1）mysqldump，MySQL安装包自带的备份工具，单线程备份。2）mydumper是Facebook、SkySQL、Oracle、Percona开发者维护的多线程备份工具，可以实现行级并行备份。https://github.com/maxbube/mydumper3)mysqlpump是MySQL5.7推出的备份工具，可以实现表级别的并行备份。4)MySQLShellMySQLShell8.0.21引入了一个工具——util.dumpInstance()，可以实现行级并行备份。本工具对备份实例和恢复实例的版本有要求：备份实例>=5.6，恢复实例>=5.7。5)SELECT...INTOOUTFILESQL命令可以直接将表记录导出到文件中。下面说说这些工具的异同点：从实现原理来看，mysqldump、mydumper、mysqlpump、MySQLShell可以归为一类，本质上都是使用SELECT*FROMTABLE来备份数据，但是在此基础上，通过全局读锁+REPEATABLEREAD事务隔离级别，实现了数据库的一致性备份。SELECT...INTOOUTFILE充其量是一个命令，而不是一个工具，更不用说数据库的一致备份了。mysqldump、mydumper、mysqlpump从导出的内容中将备份结果以INSERT语句的形式保存，如：INSERTINTO`t1`VALUES(1,'aaa'),(2,'bbb'),(3,'抄送');而MySQLShell和SELECT...INTOOUTFILE将备份结果保存为CSV格式，例如1aaa2bbb3ccc正在恢复，每个工具对应的恢复工具不同。具体来说，mysqldump和mysqlpump对应的恢复工具是mysql客户端，所以是单线程恢复。mydumper对应的恢复工具是myloader，支持多线程恢复。util.dumpInstance()对应的恢复工具是util.loadDump()，它实际调用的是LOADDATALOCALINFILE命令，支持多线程恢复。SELECT...INTOOUTFILE对应的恢复命令是LOADDATA。三、mysqlbackupVSmysqldump以下是MySQL官方提供的一组数据，对比mysqlbackup和mysqldump的备份恢复时间。第一张图备份时间对比，mysqldump是mysqlbackup的49倍。第二张图对比恢复时间，mysqldump比mysqlbackup快80倍。这样，我们也可以看出逻辑备份工具和物理备份工具在备份和恢复速度上的差距。不幸的是，这里没有测试mydumper。毕竟对于数据量大的实例，如果一定要使用逻辑备份，一般倾向于使用mydumper而不是mysqldump。4.如何检查备份的有效性为什么要检查备份的有效性，主要有两个原因：验证整个备份链路的可靠性。包括备份参数是否完整，备份集是否有效，备份介质是否损坏等。通过检查备份的有效性，构建一个完整的自动恢复系统。很多时候，影响数据库恢复时间的不是备份集太旧，而是手动恢复过程中不熟悉的命令、环境和流程导致的额外耗时。如何检查备份的有效性，常用的方法有3种：根据备份恢复实例，查看实例是否可以启动。并在此基础上进行随机查询。这种检测方法是最简单的。一般来说，如果实例可以启动，并且随机查询没有问题，就说明备份集可用。但是有备份集不代表备份集能满足我们的需求，比如常见的搭建从库的方式。此外，一些常见问题，如备份中断、参数指定不准确等，也无法通过这种方式进行检测。在1的基础上，创建副本。如果从库在追主库的过程中没有报错，很可能是主从数据一致。当然，这只是大概率，不是100%。在2的基础上，使用pt-table-checksum校验主从数据的一致性。如果校验结果为OK，说明主从数据一致，间接证明了备份的有效性。但是由于pt-table-checksum在运行过程中会在chunk级别对表加S锁，对频繁更新的业务还是有一定的影响。一般来说，在线使用方法2就足够了。方法三，因为检查主从数据的一致性需要比较长的时间，如果要检查的备份集很多，会影响检查的效率。5、RTO和RPO在衡量一个数据中心的容灾能力时，有两个常用的指标：RTO：RecoveryTimeObjective，恢复时间目标。意思是灾难发生后，必须在这段时间内恢复数据。这段数据恢复期间，服务不可用，所以RTO也是服务允许的最大不可用时间。如果我们要求服务的最大不可用时间是30分钟，那么RTO就是30分钟。RTO越小，容灾系统的恢复能力越强。RPO：RecoveryPointObjective，数据恢复点目标。指灾难发生后数据可以恢复到的时间点。例如，我有一个每天0:00执行完整备份的系统。当系统出现故障时，将根据上次备份进行恢复。如果系统在凌晨3点停机，我们将丢失3小时的数据。在极端情况下，系统会在23:59发生故障，我们会丢失24小时的数据。这里的24小时就是这个系统的RPO。RPO越小，系统越能保证数据的完整性。RTO、RPO、灾难在时间轴上的关系如下图所示：可以看到，RPO是针对数据丢失，RTO是针对服务宕机，两者没有必然联系。理想情况是RTO和RPO都为0，即当灾难发生时，系统会立即恢复，数据不会丢失。当然，RTO和RPO越小，需要投入的成本就越高。具体在MySQL中，要降低RTO和RPO，可以从以下几个方面入手：1）RTO增加备份频率，缩短备份周期。选择物理备份，而不是逻辑备份。添加延迟从库。恢复过程的自动化。2）RPO提高了备份频率，缩短了备份周期。搭建BinlogServer，用于备份Binlog。当发生故障时，我们可以根据备份和Binlog进行时间点恢复。添加延迟从库。6.总结从RTO的角度来说，尽量选择物理备份，而不是逻辑备份。如果要使用逻辑备份，应该尽量选择多线程备份工具和多线程恢复工具。从RPO的角度来说，应该尽可能的提高备份频率，缩短备份周期。但每个硬币都有两个方面，使用物理备份或增加备份频率无疑会增加存储成本。因此，在确定备份策略和选择备份工具时，需要结合存储成本考虑业务的RTO和RPO。大部分公司都会采用统一的备份策略，比如每天做一次全量备份。虽然灾难很少发生，但是开发和DBA童鞋们也应该充分认识其中的风险，并制定相应的预案和业务支持计划。另外，对于线上的核心业务，如果只有备份，仍然很难有效降低数据库服务的RTO和RPO。建议部署延迟从库。
