数据库备份策略_MySQL中如何选择合适的备份策略和备份工具

数据库备份的价值显而易见，可以说，它是数据安全的最终屏障。因此，针对备份，我们一般有以下规范：

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

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

备份有多种类型，其中一种类型是物理备份，另一种类型是逻辑备份，这两者之间存在显著差异，MySQL提供了专门的备份工具，这些工具在执行备份操作时表现出色，备份与恢复的速度存在明显对比，评估备份是否有效是至关重要的步骤，需要采取特定方法，RTO和RPO是衡量恢复能力的关键指标，备份的种类繁多，主要分为物理备份和逻辑备份两种方式

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

优点：

缺点：

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

优点：

缺点：

离线备份 VS 在线备份

备份在非工作状态下进行，这种备份方式也称作 "静态备份"。进行这种备份时，系统必须处于关闭状态，因此只能采用物理手段，也就是完整复制所有实体数据文件。

数据远程复制，亦被称作 "实时备份"，指系统运行期间执行的复制操作。这种操作方式，既能实施实体数据复制，也能够执行结构化数据复制。

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

全量备份 VS 增量备份

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

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

一般情况下，运用物理复制来达成增量复制较为容易，以MySQL为例，只需要确认数据页的LSN是否出现变动。

对于逻辑备份而言，完成起来十分困难，比如通常按照特定时间点进行增量复制，然而，确保某个时间点前的信息完全不发生改动或移除，实际上几乎不可能。

MySQL中的备份工具物理备份

物理备份相关的工具有：

这三个方案的运作方式大体一致，都是通过备份环节，复制实际数据和日志记录，随后借助系统崩溃恢复机制，将数据文件还原到备份完成时的那个特定时点。

逻辑备份

逻辑备份相关的工具有：

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

从运作机制上看，、 、、 MySQL Shell与同类软件相似，其核心功能在于借助 * FROM TABLE指令来复制数据，而其特别之处在于运用全局读锁以及READ事务隔离机制，以此确保备份过程符合数据库的一致性要求。 ... INTO 命令功能有限，并非真正意义上的工具，自然也无法达成数据库的一致性备份目标。根据导出的信息可知，、、会将备份内容记录为文本形式，例如，`t1` (1,'aaa'),(2,'bbb'),(3,'ccc');

而 MySQL Shell借助... INTO功能将备份内容以CSV格式进行存储，例如，1,aaa

2 bbb

ccc正在复原，各个工具的复原手段各不相同。其中，针对的复原手段是mysql客户端，因此是单线程复原。而针对的复原手段，则支持多线程复原。util.()的复原手段是util.()，这个工具本质上执行的是LOAD DATA LOCAL指令，同样支持多线程复原。...对应的恢复指令是装载数据。在VS中

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

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

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

通过这个，我们同样可以了解逻辑复制手段同实体复制手段在数据复制与恢复速率方面的不同。

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

终究，对于包含海量信息的场景，若坚持选择逻辑恢复方式，多数人通常会挑选这个方案，而非那个途径。

如何检测备份的有效性

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

确认备份流程的稳固性，考察备份配置是否齐全，确认备份数据是否可用，查验备份载体有无损坏。借助验证备份数据，构建一套周密的自动回溯机制。通常情况下，导致数据库回溯耗时过长的并非备份数据陈旧，而是人工回溯环节，由于指令、条件、步骤掌握不熟练，造成的额外时间损耗。

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

通过备份恢复测试，检查实例能否正常启动，然后进行随机数据查询，这种验证方式最为简便，通常情况下，如果实例能够成功启动，且随机查询数据正常，就表明该备份集合是有效的，然而备份集合有效，不代表它能够满足所有要求，例如，它可能无法用于构建从属数据库。此外某些普遍情况，比如数据备份中止、参数设定不精确，均无法借助这个方法识别。从第一点出发，开始进行复制操作。假如从数据库在同步主数据库时未出现异常，极有可能表明主从数据内容相同。当然这仅是可能性较高，并非绝对保证。从第二点入手，借助pt-table-check工具验证主从数据库的一致性检验无误时，表明主体与从属数据相符，这便从侧面反映了备份确实可用。不过pt-table在执行期间，会对数据块施加共享锁，对于数据变更频繁的应用场景，会造成一定阻碍。

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

方法三，需要核实主次信息是否吻合，这个过程比较费时，假如待查验的备份资料数量众多，反而会降低查验工作的速率。

RTO 和 RPO

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

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

能够理解，RPO是应对信息遗失的指标，RTO是衡量系统不可用期的标准，这两项考量彼此并不存在必然的关联性。

最理想状态下，RTO与RPO均等于零，这表明一旦遭遇灾难，系统能够即刻复原，并且数据不会遗失。然而，RTO、RPO数值越小，所需投入的代价也越昂贵。

针对MySQL系统，要减小恢复时间目标与恢复点目标，可从以下途径实施措施：首先，优化数据库架构，其次，增强备份机制，再者，提升系统资源利用率，最后，改进故障切换流程。

RTO

提升数据保护频次，减少数据复制间隔，优先采用实体复制而非结构复制，引入从库的延迟机制，实现复原作业的自动化处理。

RPO

提升数据保护频次，压缩资料存档时限。构建数据冗余机制。一旦系统遭遇问题，即可借助资料副本实施时间回溯。增设从库的延迟机制。归纳总结

从RTO的考量来看，应当优先选用实体备份，而非逻辑备份，若需采用逻辑备份，则应尽可能选用支持多任务并行操作的备份软件以及支持多任务并行操作的恢复软件。

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

然而，事物总有正反两面，采用实体复制手段或提升数据存储频次，肯定要付出更高的数据保管代价。

因此，制定备份方案和挑选备份软件时，必须依据业务可接受的中断时长和恢复点目标，同时也要权衡存储费用。

很多企业会实施一致的数据保护措施，例如每日进行完整备份。尽管重大事故并不常见，但研发与数据库管理人员必须清楚认识到这种做法的潜在问题，并且需要准备相应的应急计划以及业务保障措施。

此外，针对网络中心的关键作业，倘若仅实施数据复制，依然难以显著缩短数据库支持服务的恢复时间目标与恢复点目标，应当配置存在时间差别的辅助数据库。