共计 4092 个字符，预计需要花费 11 分钟才能阅读完成。
工具与资源核心
帮忙开发者更加高效的工作，提供围绕开发者全生命周期的工具与资源 https://developer.aliyun.com/…
一、故事的起源
在 IT 圈内，“删库跑路”曾经成为程序员常常提及的一句玩笑话。尽管是玩笑话，但却反映了数据库内数据对企业的重要性。2020 年的“微盟事件”就间接让香港主板上市公司微盟团体的市值一天之内蒸发超 10 亿元，数百万用户受到间接影响。
以小编多年的数据库从业教训而言，删库跑路事件不常有，但因大意导致的误删数据却不足为奇。要么手误、要么公布的代码存在 bug，导致数据被误删，虽是无心，然而破坏力却也不小。
均匀每两个月就会有一个相似下面的用户，向咱们的值班同学寻求帮忙，复原误删的数据。
对于这些大意的马大哈，PolarDB-X 是如何帮忙他们疾速精准的找回失落数据，援救他们奄奄一息的工作呢？
首先咱们依照操作类型，将误删数据的 Case 进行分类：
• 行级误删，常见指数：5 星
应用 delete/update 语句误删 / 改多行数据
• 表级误删，常见指数：3 星
应用 drop table 误删除数据表
应用 truncate table 语句误清空数据表
• 库级误删，常见指数：1 星
应用 drop database 语句误删数据库
PolarDB-X 针对下面几种不同的数据误删场景，打造了多项数据恢复的能力，帮忙用户疾速复原数据：
本文作为数据恢复系列的第一篇，将重点介绍 PolarDB-X 针对行级误删场景所打造的 SQL 闪回性能。其它的能力将在后续的文章中具体介绍。
二、事故现场
首先，咱们以一个理论误删数据的事变收场。
咱们来梳理下事变的工夫线：
• T1：DBA 小明保护了一张员工表，外面记录着公司的员工信息。
• T2：Mary 因为集体起因到职了，小明须要删除 Mary 的记录，因而他到数据库外面执行了一条 DELETE 语句，本意是想删除用户 Mary 的记录，然而因为手贱，漏了一个 and 语句，导致员工 Ralph 的数据也被意外删除。
• T3：此时业务仍在持续，John 被删除，Tim 和 Jose 被插入到表中。而此时大意的小明发现了数据被误删，迫切希望复原数据。
接下来，围绕这一次的数据误删事变，看看是 PolarDB-X 是如何援救大意的小明的？
三、现有计划
在介绍 SQL 闪回之前，咱们先简略理解下目前支流的数据库是怎么应答这种行级数据误删的。依照复原形式大抵能够分为如下两类：
• 复原数据至误删除前的工夫
• 回滚误删除操作
（一）复原数据至误删除前的工夫
1. 基于 PITR
Point-in-time Recovery(PITR): 顾名思义就是利用备份文件将数据库复原到过来任意的工夫点。目前支流的数据库都反对该能力。尽管各家数据库 PITR 的实现形式不尽相同，然而整体的思路还是统一的，如下图所示：
首先依赖数据库的全量备份集将数据恢复到过来备份时的工夫点（通常每隔几天备份一次），再依赖增量的数据变更记录，复原数据至须要的工夫点。PolarDB-X 的 PITR 的实现思路也是如此，不过因为分布式事务的存在，PolarDB-X 还做了更多的工作来保障分片间的数据一致性，这部分的工作将在后续的文章中具体介绍。
有了 PITR 的能力后，一旦呈现数据误删，最间接的想法便是通过 PITR 将数据库复原到数据被误删前的工夫点，这种计划的益处是能够将数据库复原到用户须要的任意工夫点，然而也存在一些问题：
• 复原工夫长：因为须要将整个数据库进行复原，整体耗时较长。即便只误删了 100 条数据，通过这种形式也须要复原整个数据库（或者整张表）的数据才行。
• 额定的存储空间：出于数据安全思考，PITR 通常会将数据恢复到一个新的数据库中而并非间接笼罩原库中的数据，这就须要额定的存储空间存储新库的数据，当数据量较大的的场景，这部分开销还是很可观的。
• 局部业务数据失落：以下面的例子来看，误删数据后业务仍在持续读写数据库。如果将数据库复原到误删前的时刻，误删后的失常业务数据也会失落。
下图针对咱们的事故现场，给出了基于 PITR 复原到数据误删除前的示例图。从图中能够看出，复原到 T2 时刻，尽管误删的数据找回来了，然而 T2 ~ T3 范畴内失常的业务改变也失落了。
2.Flashback Query
针对 PITR 复原工夫长的问题，也有很多优化策略，其中比拟有代表的是 Oracle 以及 PolarDB- X 的 Flashback Query 性能。
Oracle 的 Flashback Query 基于 undo 信息，间接从中读取数据的前镜像结构历史快照，将数据恢复到误删除前的工夫点。PolarDB-X 的 Flashback Query 实现相似，也是利用 undo 表的信息，读取历史工夫点的数据，不过绝对于单机数据库，咱们在复原到过来工夫点的时候，还须要思考到不同数据分片间的数据一致性，敬请期待后续的文章，此处就不开展介绍了。
上面咱们以 Oracle 为例对下面的场景进行阐明。如果 T2 对应的工夫点是：2021-04-06 19:23:24，那么在 Oracle 中，通过 Flashback Query 性能，我只须要执行上面的 SQL，便能查问到 2021-04-06 19:23:23 时刻 Employee 表的数据：
select * from employee
as of timestamp
to_timestamp(‘2021-04-06 19:23:23′,’YYYY-MM-DD hh24:mi:ss’)
基于查问到的误删除前的数据，用户便能疾速复原数据。
Flashback Query 这种基于 Undo 信息复原的形式，大大提高了数据恢复的速度，同时也无需额定的存储空间，绝对于 PITR，复原效率更高。然而这种形式也存在两个问题：
• 局部业务数据失落: 因为实质上数据仍是复原到误删前的工夫点，该问题依然存在。
• 时效性问题：flashback 应用的是 undo 表空间的 Undo 数据, 一旦 undo 数据因为空间压力被革除, 则会呈现无奈 flashback 的状况。因而这种形式只能反对较短时间内的数据回滚。
（二）回滚误删除操作
既然数据库会通过增量日志来记录数据变更，那么有没有可能间接通过增量日志来回滚误删除操作呢？答案是必定的，其中比拟有代表性的就是 MySQL 的 Binlog Flashback 工具。
当 MySQL 的 binlog format 设置为 row mode 的时候，binlog 中会记录数据行的变更。
对于上图中的 employee 表，当我执行如下的 delete 语句删除了两行数据后，对应的 binlog 中的记录是如下图所示：
从上图中能够看到，binlog 会记录下被 delete 语句删除的每行数据，update 也是如此。
binlog flashback 工具正是基于这样的信息，依照操作的工夫范畴、操作类型将 binlog 中对应的数据变更进行逆向，生成对应的回滚 SQL，进行数据恢复的。
例如对于下面的 delete 操作，执行的工夫是 22:21:00, 那么咱们只须要在 binlog 中找到 22:20:59~22:21:01 之间的 delete 操作，并将其转换成对应的 insert 语句，如下所示，即可找回失落的数据。
insert into test.employee values(‘2’, ‘Eric Zhang’);
insert into test.employee values(‘3’, ‘Leo Li’);
这种基于增量日志回滚操作的复原形式，复原速度较快，且因为增量日志的保留工夫较长，复原数据的时效性绝对于 Oracle 的 Flashback Query 的形式也较长。然而这种形式也存在一些问题：
• 回滚范畴过大：现有的 binlog flashback 工具只能通过 SQL 执行工夫、SQL 类型等无限的条件在 binlog 中筛选数据并回滚。如果在筛选的工夫范畴内，有失常的业务操作的话，那也会被回滚。下图在咱们事故现场，用过这种复原形式会存在的问题：
从上图中看出，当咱们应用 flashback 工具对 T2~T3 范畴内的所有 DELETE 操作进行回滚的后，比理论须要复原的数据多出 1 行。如果须要复原数据的话，还须要进行人工比对，剔除这部分不须要复原的数据。而这部分人工剔除的工作往往也比拟耗时且容易出错。
四、配角退场 – SQL 闪回
PolarDB-X SQL 闪回性能，从实现形式上看属于对误操作进行回滚。不过绝对于现有的计划，提供了准确到 SQL 级的回滚能力以及易于上手的操作界面。
（一）SQL 级的回滚能力
何为准确到 SQL 级的回滚能力，即只针对误操作影响的数据行进行回滚，不影响业务失常的数据变更。
同样以下面的误删场景为例，咱们看下 PolarDB-X SQL 闪回是如何对误删操作回滚的？
首先每一条在 PolarDB-X 中执行的 SQL 都会调配惟一的身份证号（TraceID），这保障了所有的改变都是能够追溯的。
当咱们发现误删数据后，只须要依据误删除 SQL 的 TraceID，通过 SQL 闪回即可准确的找到这条 SQL 误删除数据并进行回滚。如上图所示，咱们误操作的 SQL 的 TraceID 是：abcm321, 那么依据这个“身份证号”，SQL 闪回便能精准的找到被这条 SQL 误删除的数据，并生成相应的回滚 SQL。
（二）疾速上手
说了这么多，SQL 闪回在 PolarDB-X 中具体是如何应用的呢？SQL 闪回提供了十分便捷的操作形式，只需三步即可实现数据恢复，充沛关照小明着急的情绪。
1. 在 SQL 审计性能中找到误操作 SQL 的“身份证号”
2.SQL 闪回页面填写误操作 SQL 执行的大抵工夫范畴和 TraceID，提交 SQL 闪回工作即可。
3. 期待闪回工作实现下载复原文件进行数据恢复即可。
五、总结
本文次要围绕数据误删中的行级误删状况，介绍了 PolarDB-X 的 SQL 闪回是如何帮忙用户复原数据的。绝对于现有的数据恢复计划，SQL 闪回的 SQL 级的回滚能力以及易于上手的操作界面可能帮忙用户更加精准、更加疾速地复原误删数据。
当然，数据安全是一个永恒的话题，针对不同的数据误删场景，PolarDB-X 曾经打造了多项利器来保障用户的数据：PITR、Recycle Bin、Flashback Query 等等。后续的文章将对这些能力逐个介绍，敬请期待~
