YashanDB V23.4 LTS全库闪回新特性解读

柏杨 YashanDB存储研发技术专家

本文主要对YashanDB V23.4 LTS新版本的全库闪回新特性进行原理探讨与技术解析。

证券交易系统突发数据异常，三甲医院电子病历系统遭遇误操作...在这些极端故障场景中，传统数据库恢复方案正面临前所未有的挑战。传统数据库恢复技术（Point-In-Time-Recovery, PITR）通过全量数据库备份进行整库恢复，需要耗费数小时进行全量备份回滚与日志解析，且恢复效率受限于数据库大小。导致难以快速响应紧急故障，错失降低损失的黄金时间，造成交易停摆、医疗数据混乱等严重后果。YashanDB V23.4 LTS新版本中重磅推出全库闪回特性，基于闪回快照点技术及并行异步刷盘技术，开启闪回对业务性能影响可降低至8%；并通过闪回日志快速过滤技术，可高效解决传统闪回技术资源消耗大、恢复时间长的问题。

PITR和全库闪回技术的对比

PITR与全库闪回的主要区别在于对数据库的回退处理方式，前者是整库回退，后者能实现精准回退。

PITR技术

传统的PITR数据库恢复技术主要是通过备份集对数据库进行全量数据回退，再基于redo进行回放重演到目标时间点。



图1 PITR技术工作原理架构

如图1所示，当T3时刻数据库出现了故障需要回退到T2时刻消除影响，此时便需要使用T1时刻的备份集将数据库整体回退到T1时刻，再回放T1到T2之间的redo实现恢复。

PITR的恢复时间通常与数据库的量级以及回放的redo量相关，通常数据库的量级都非常大，这就导致PITR非常耗时。

全库闪回技术

与PITR基于备份集的整库回退不同，全库闪回只追踪记录修改页面的变化并产生闪回日志，通过闪回日志对数据库进行精准的局部回退。



图2 全库闪回技术工作原理架构

如图2所示，同样是从T3恢复到T2，全库闪回会选择将数据库回退到距离T2最近的一个闪回快照点，再从该点回放redo实现恢复。

假设闪回快照点到T3之间修改了三个页面，则会记录这三个页面修改之前的内容并产生闪回日志，后续将数据库从T3回退到闪回快照点时只需要应用闪回日志即可，避免对数据库未产生变化的内容进行无效的回退。

**全库闪回的恢复时间与数据库量级无关，只与回退目标点的业务量有关。

**

下面将从四个方面对比全库闪回和PITR两项技术。

全库闪回应用场景

全库闪回的应用场景十分广泛，下面通过两个具体业务场景的痛点问题，对比分析全库闪回相较于PITR在解决问题上的优势。

场景一：数据故障场景处理

在数据库正常运行过程中，遇到一些误操作等情况造成了部分数据错误，需要在最短的时间内进行恢复，减少损失，降低影响。

使用PITR技术需要基于备份集进行恢复，在数据库量级大的情况下，应用备份集及其耗时，恢复时间长，因为局部错误将整个数据库回退恢复，代价太高，得不偿失。

使用全库闪回基于闪回日志进行恢复，仅追踪恢复因误操作造成的部分错误数据，实现精准恢复，不受数据库量级影响，能以最小的代价进行快速高效的恢复。

场景二：主备业务模拟演练

以证券行业为例，业务系统通常为主备部署，在休市期间会使用备库进行开市的业务模拟演练，提前识别灾备风险。当需要进行业务模拟演练时，主库业务不停的情况下，需要将备库failover成主库进行演练，并需要保证演练完毕后能重新变为备库恢复正常的主备状态。

使用PITR技术需要在演练前生成备份集，演练后应用备份集，备库量级大的情况下，演练前的准备时间以及演练后的恢复时间都很长。

使用全库闪回技术无需生成和应用备份集，代表着演练前无需准备时间，演练后仍可以实现快速恢复。

图3 主备形态业务模拟演练场景示意图

全库闪回关键技术

接下来进一步解析全库闪回的两个关键技术“快照点技术”和“快速恢复日志过滤技术”。

首先是全库闪回快照点技术，全库闪回主要通过追踪修改页面的变化并产生闪回日志来实现数据库恢复，因此闪回日志的产生与记录至关重要。

图4 全库闪回快照点技术架构图

如图4所示，初始buffer pool里的三个页面A、B、C都是A0、B0、C0的状态，以A页面举例，T1到T5时刻，A页面从A0修改到了A3，理论上是需要记录A0、A1、A2三个闪回日志，这样才能确保A页面能通过闪回日志从A3回退到最初的A0。

这种记录闪回日志的方式面临两个问题：

1.业务运行过程中，每次修改页面都要产生闪回日志，对性能影响较大。

2.频繁记录闪回日志容易导致空间膨胀过快。

为了解决上述问题，引入了全库闪回快照点技术，在两个快照点之间同一个页面的修改只记录一次闪回日志，降低性能影响，避免空间浪费。

比如这里针对A页面而言，在T3和T5两个快照点之间，A从A1修改成A2，又从A2修改成A3，那么仅记录一个A1的闪回日志。

同时为了降低记录闪回日志IO对正常业务的影响，对于闪回日志的记录都是采用异步刷盘。

第二个是全库闪回快速恢复日志过滤技术。全库闪回进行数据库恢复过程中，如何快速有效的应用闪回日志是影响恢复效率的关键。

图5 全库闪回快速恢复日志过滤技术架构图

这里同样面临两个问题：

1.如何根据闪回目标时间点快速确定数据库需要回退的位置，并应用哪些闪回日志？

2.应用闪回日志的过程中，是否所有日志都需要应用，如何进行优化过滤减少消耗？

针对第一个问题，因为闪回日志是以快照点为区间进行记录的，因此当需要回退到某个目标时间点时，需要找到离目标时间点最近的快照点进行回退，再从快照点回放redo恢复到指定时间点。

如图5所示，假设需要从T5恢复到T2，则需要先回退到T1这个快照点，再从T1回放redo到T2。

针对第二个问题，从T5回退到T1时刻，以A页面举例，理论上是需要应用A1、A0两个闪回日志将A页面回退到A0状态，实际上最终目标都是恢复成A0，因此A1这个闪回日志是可以跳过的。

为了实现应用闪回日志的优化，引入了闪回日志过滤技术，当同一个页面在多个快照点区间都产生了闪回日志，则只应用时间最早的闪回日志，其余均跳过。

假设从T5回退到T1，需要横跨两个快照点区间，对于A页面，分别在两个区间产生了A0和A1两个闪回日志，则实际应用时只应用A0即可，跳过A1，从而达到过滤提升恢复速度的效果。

基于以上技术，可以确保全库闪回在对业务性能产生极小影响的前提下，实现数据库整库快速恢复到任意时间点。

图6 相同业务在不同数据库量级下全库闪回与PITR恢复耗时

如图6所示，数据库量级越大的情况下，全库闪回的局部精准恢复相较于PITR的效果越好。

总结

YashanDB V23.4 LTS新版本此次新增全库闪回特性，语法层完全兼容Oracle，无缝融入现有技术栈，并通过精准秒级回滚、低资源消耗的技术特性，为用户筑牢 “业务永续” 屏障。后续也将从可用性和部署形态等方面进一步提升全库闪回能力，如压缩闪回日志提升空间利用率、支持共享集群部署模式等，以更强大的企业级高可用能力，成为驱动企业数字化转型的关键引擎。