快速恢复到任意时间点

在动漫哆啦A梦里，有两个让人记忆犹新的神奇法宝：可以直接到达目的地的任意门，和回到过去任何时间的时光机。动漫中的法宝与这篇介绍数据库备份的技术文章有什么关系呢？仔细琢磨一下，在数据库备份领域，这两点不恰好用户梦寐以求的两项功能吗：

• 快速恢复（数据立即可用）：对于构建高可用的在线服务意义重大。一旦在线服务的数据库故障，用户希望尽可能快速的恢复新的数据库。当然在数据备份领域，有专门衡量恢复速度的指标RTO（Recovery Time Objective)，指从开始恢复到完成恢复的时长。
• 恢复到任意时间点：意义在于数据管理的健壮性。由于代码bug或人工误操作产生的脏数据，是无法通过恢复最新数据修正的，必须恢复到历史时间点，或根据历史时间点的数据进行在线数据订正。通常恢复的数据所对应的历史时刻，与期望恢复的时刻是有时差的，数据备份领域为了衡量这个时差的大小，也有对应的衡量指标是RPO（Recovery Point Objective）。狭义的RPO指可恢复时间点与当前时间的时差，而本文探讨的广义RPO概念，是指可恢复时间点与任意历史时间点（包含当前时间）的时差。

正如哆啦A梦需要用两个不同的法宝，分别实现两种不同的目标。数据备份系统，             通常会使用不同的技术方案分别实现低RTO或低RPO，而难以两者兼得，即很难做到恢复到任意时间点并立即可用。我们以阿里云数据库RDS为例：

• RDS灾备实例：这项功能基于日志实时同步技术，实现多个RDS实例之间的实时同步。当原实例发生故障，业务都可以快速切换使用灾备实例，这就体现了“恢复数据立即可用”，即低RTO。然而灾备实例只能提供当前时间点的灾备恢复，无法回滚数据到过去任意时间点。当用户原实例写入了脏数据，或执行了误操作，灾备实例的数据也会同步引入了脏数据和误操作结果。因此RDS的灾备实例功能，无法做到指定任意时间点的低RPO。另外灾备实例需要用户承担两个RDS的成本，通常成本远高于仅存储备份数据的方案，这也成为用户采用该方案的顾虑之一。

• RDS备份恢复：这项功能基于数据库的冷备份和日志备份技术，通过备份数据恢复以及日志回放，实现创建一个过去任意时间点的实例（也成为RDS克隆实例），这恰好符合“恢复到任意时间点”（低RPO）的需求。然而RDS备份恢复功能并不是立即可用的，与灾备实例相比，RDS恢复功能产生的克隆实例是按需创建的，从备份数据到克隆实例的数据，需要有较长时间的数据拷贝和日志回放过程。因此RDS备份恢复功能，无法做到恢复到任意时间点的低RTO。

有没有一种解决方案能够同时解决RTO和RPO问题呢？2021年云数据库RDS和数据库备份DBS产品，针对这一痛点，联合发布了一项的新的备份恢复功能——应急恢复。该功能在原有的RDS备份恢复功能基础上，结合了基于CDM（Copy Data Management）技术的DBS沙箱功能，赋予用户同时使用任意门和时光机的能力，即分钟级快速恢复生成一个任意时间点的新数据库实例。这项功能的入口在“RDS控制台-实例列表-备份恢复-应急恢复”前端标签下可以找到。用户同样也能使用DBS控制台的导入数据源和沙箱实例功能完成相同功能的配置。

使用RDS应急恢复（DBS沙箱）功能

开启应急恢复功能

在RDS控制台，打开实例的管理页面，选择“备份恢复”标签中的“应急恢复”标签。点击“开启/管理DBS应急恢复”

接下来会跳转到DBS控制台，如果该RDS实例没有开启应急恢复功能，则会显示以下引导页面。其中前2个步骤是自动完成的，需要最多等待1分钟完成，第3步用户可选择付费模式（目前只有容量版可选）和保留天数。点击“确认”后，应急恢复功能就开启成功了。

之后页面会跳转到DBS控制台的“备份任务配置页面”，如果页面提示沙箱状态为“已开启”，表示已开启成功。注意，第一次开启RDS应急恢复（DBS沙箱）功能后，DBS还会有一段时间的数据准备过程。当准备过程结束，该页面的沙箱实例范围栏会提示可恢复的时间范围。

创建RDS应急实例

在RDS控制台应急恢复标签下，点击“创建应急实例（DBS沙箱实例）”按钮，页面会跳转到如下DBS控制台的创建沙箱实例页面。在该页面，首先选择恢复时间点（第一次开启后默认可选时间范围，为最近一次RDS备份时间到当前时间）。然后选择创建沙箱的规格、地域、专有网络，以及虚拟交换机（这些选项是为了生成打通到用户专有网络的沙箱实例IP），接下来就可以点击立即恢复。

接下来页面会跳转到DBS控制台的沙箱实例页面，用户可以看到刚创建的沙箱实例。沙箱实例的初始状态为“创建中”，大约1-2分钟后状态会变为“运行中”，同时会生成沙箱实例的地址（对于RDS MySQL应急实例为用户专有网络IP和3306端口），以及连接到该实例的DMS链接。用户可选择自行连接到沙箱实例，或通过DMS服务白屏化管理实例。

关于创建应急（沙箱）实例，需要注意几点：

• 沙箱实例“创建中”状态的持续时间，可能还与RDS原实例的日志量有关。最坏情况下，最大可能会增加10分钟的创建时间。
  
• 沙箱实例的账号与RDS原实例完全相同，包括客户端白名单。
  
• 沙箱实例是可写的，写入的数据不影响原实例，删除沙箱实例后，写入沙箱实例的数据都会丢失。

应用场景

RDS应急恢复（DBS沙箱）功能，相对原有的RDS备份恢复功能，优势在于能够更快生成一个历史时间点的实例。不过在性能、SLA和平台管理能力方面，应急实例都弱于RDS实例（当然计费比RDS实例也更低）。因此应急实例并不适合替代RDS实例作为用户的生产实例。综合以上的优缺点，我们认为应急实例适合以下几种场景：

• 开发测试：许多企业的集成测试，依赖真实的在线数据内容和数据量。面向开发者的高效开发测试平台，对测试速度和即时性的要求很高，对于测试数据库，通常要求实例立即可用，并且多个测试用例能够并发且互不干扰的访问。RDS应急实例就非常满足以上需求，用户可以快速创建多个应急（沙箱）实例，甚至可以通过OpenAPI集成到自己的CI/CD系统，搭建面向线上数据的高性能测试服务。
  
• 脏数据订正：运维误操作或程序bug，都可能导致用户的生产库实例写入了脏数据，通常这类错误可以被快速发现，但如何订正脏数据，成为了许多企业运维人员最头疼和不想面对的难题。此时运维人员最希望获得的帮助，就是立即有一个状态在误操作或程序bug触发前的数据库实例，作为在线实例的对照，从而通过数据对比来进行脏数据订正。RDS应急恢复例在这一场景就是解决痛点问题的最好方案。
  
• 历史分析：企业的历史数据分析通常比较复杂，常用的解决方案是将数据库数据导入到离线数据仓库后分析。但对于简单的历史数据报表分析，例如单实例上的SQL查询能够搞定的简单报表，用户可以用应急（沙箱）实例替代数据仓库，不仅技术难度更低，而且成本也会明显下降。
  

注意以上这些场景中，应急（沙箱）实例仅仅提供了最核心的一个环节，即快速恢复历史数据，并没有解决所有环节的问题。以脏数据订正场景为例，完整的解决方案需要包括数据的对比、数据轨迹查询、生成并订正数据等多个能力。DBS产品今年将主力打造这类基于应急恢复（沙箱）功能的场景化解决方案。

了解DBS沙箱背后的技术

全量、增量和日志备份，与RTO/RPO的关系

主流的数据库，例如MySQL、SQL Server、Oralce，其物理备份方案都可分为三种类型：全量备份、增量备份、日志备份三种类型。他们各自的原理、开销和对RPO影响各部相同，总结如下。

全量备份和增量备份，产生的RPO与备份周期有关。考虑备份开销等因素，用户通常会每天或每周进行一次全量备份，或每小时或数十分钟进行一次增量备份。日志备份由于是持续运行，因此可以直接将RPO降低到秒级。当这三种备份类型组合起来，整体的RPO等于每种备份RPO的最小值。因此我们可以得到第一个结论

如果需要RPO降低到秒级，那么必须包含日志备份（因为依赖关系，也需要全量备份）

我们接下来分析备份类型与RTO的关系。通常备份数据需要经过数据拷贝，才能会恢复给目标实例使用。考虑1T的全量数据，以100MBps的速度拷贝，那么拷贝的时间将长达3个多小时，也就意味着RTO也会大于3小时。CDM/存储虚拟化技术为解决这个问题提供了全新的思路，通过将备份数据转换为快照，可以使得无论多大的备份数据量，都能在分钟或秒级时间内，完成克隆和远程挂载，即将总体RTO降低到了秒级或分钟级。

然而日志备份无法转换成快照，因此如果需要同时实现分钟/秒级的RPO和RTO，需要将日志回放的时间也考虑进去。也就是说总体RTO等于基于CDM技术的秒/分钟级RPO与日志回放RPO之和。首先，日志回放的时间与回放的数据量成正比；另一方面，全量和增量备份频率越高，那么快照频率越高，日志回放的数据量越小。第三，因为增量备份的开销远小于全量备份，因此需要尽可能使用增量备份而不是全量备份。

如果需要RTO和RPO同时降低到秒/分钟级，那么必须使用CDM/存储虚拟化技术如果同时还需要降低源库的开销，那么必须使用高频的增量备份和低频的全量备份相结合

接下来我们会继续解读以下2个关键技术点

1. 存储虚拟化
   
2. 高频增量备份
   

存储虚拟化技术

存储虚拟化技术，是解决备份数据到二级数据库的拷贝问题的关键技术，也是业界各种CDM解决方案必不可少的技术点。秒级快照和克隆，是存储虚拟化技术的核心能力。将存储虚拟化技术运用到数据库备份，分为2个阶段：

• 生成只读快照：对于同一个生产库产生的不同时间的备份集，使用存储虚拟化技术的备份系统，不再将这些备份集区分在不同文件路径存储，而是按时间覆盖备份数据，每当完成新数据的写入覆盖，则创建一个新的快照。产生新的快照并写入数据，不会触发数据拷贝，因此新旧快照之间的重复数据是共享的。
  
• 生成可写克隆：当备份系统需要从一个备份集恢复数据时，需要选择一个快照，然后创建基于该快照的克隆。克隆是可写的，对克隆的写入不会影响已创建的快照数据，也不会影响其他克隆的数据。
  

业界领先的存储系统实现快照和克隆能力，主要的理论基础都是CoW(Copy-on-Write)和RoW(Redirect-on-Write)，这两种设计各有利弊，工业界也有不少对这两项技术的改进实现，本文不展开论述。阿里云DBS产品针对不同的场景，综合采用了CoW和RoW两种的存储解决方案。

高频增量备份技术

数据库高频增量备份，主要关注的问题是两个开销：

• 磁盘IO开销：扫描数据文件差异造成的磁盘IO，为了降低IO开销，数据库通常会引入CBT(Changed Bock Tracking)技术。
  
• 实例加锁开销：PIT（point-in-time）拷贝通常需要对数据库实例加一定粒度的锁。
  

本文主要讨论的是RDS/MySQL实例的快速恢复，因此我们将焦点放到如何实现MySQL的CBT和无锁PIT拷贝。与SQL Server和Oracle这些商业数据库不同，MySQL作为开源数据，在CBT和无锁PIT方面，缺乏操作系统或数据库引擎层面的支持。

在CBT方面，开源MySQL都没有CBT功能，获取innodb的数据文件增量，必须扫描所有文件中的块信息。使用过xtrabackup增量备份的朋友应该都发现了这个问题，虽然一次增量备份产生的数据量远小于全量备份，但备份过程产生的磁盘IO却与全量备份相当。而xtrabackup工具的发布厂商Percona，针对这个问题在它发布的商用版本（Percona Server）中为InnoDB引擎加入了CBT功能，从而可以大幅降低增量扫描IO开销。那么问题来了，对于非Percona版本的MySQL，如何解决这个问题呢？

DBS提供的备份工具针对开源MySQL/InnoDB不支持CBT功能的现状，推出了基于MySQL redolog的旁路CBT方案。帮助用户物理用哪个MySQL版本，都能够将增量备份的磁盘IO开销控制在很低范围。

在PIT拷贝锁方面，MySQL 5.X版本在拷贝Schema数据过程中会加FTRWL锁，阻塞所有DML和DDL操作。而MySQL 8.0版本在拷贝Schema数据过程中会加Backup锁，相比5.X版本的FTRWL锁粒度变轻了，只会阻塞部分的DDL操作，但仍然对源数据库实例上的业务可能产生影响。DBS提供的备份工具，引入了无锁PIT拷贝的技术，完全避免了数据库锁对业务的影响。

欢迎加入钉钉群一起讨论交流，也欢迎加入DBS团队，简历发送到cuiyun.fcy@alibaba-inc.com