对比分析了传统数据库和国产数据库在误删表场景下的三种恢复方案，总结了各自的特点和适用性。
原文标题：国产数据库误删表恢复方案
原文作者：牧羊人的方向
冷月清谈：
* 闪回或回收站功能：通过逻辑上的快速恢复技术，在数据库层面提供分钟级的响应。Oracle、GaussDB、GoldenDB、TiDB和OceanBase都支持此功能，但具体实现方式各异，而DB2、MySQL和PostgreSQL原生不支持。
* 备份恢复：作为最传统和可靠的方案，通过将数据库恢复到误删除操作之前的时间点来实现。所有数据库都支持备份恢复，但恢复耗时较长，依赖于备份架构和存储性能。
* 延迟库：通过建立延迟备库，在主库发生误操作时，利用延迟时间窗口进行数据恢复或业务切换。虽然大多数国产数据库具备延迟备库的基本功能，但将其作为故障时的主库的产品能力尚不成熟。
文章总结了各数据库在三种恢复方案中的特点，并指出闪回/回收站功能适用于快速恢复，备份恢复是最终兜底方案，而延迟备库方案目前在国产数据库中还不具备成熟的实施可行性。同时，提出了延迟备库在资源部署、延迟阈值调整、数据完整性保障和时钟同步等方面面临的挑战。
怜星夜思：
2、文章提到了多种数据恢复方案，如果让你选择一种作为首选方案，你会选择哪个？为什么？
3、针对国产数据库，如果想进一步提升误删表后的恢复能力，你认为应该从哪些方面入手？
原文内容
前一段时间某国有大行因为国产数据库PxxDB误删表导致业务访问异常，据悉数据恢复花了几天的时间，也是因为表数据量太大导致恢复时间太长。本文将简要整理Oracle、DB2、MySQL、PostgreSQL等传统数据库和GaussDB、GoldenDB、TiDB、OceanBase等国产数据库在误删表场景下的能力和特性。
1、误删表的恢复方案
在数据库生产运维过程中，尽管有严格的流程和权限控制，但因人为失误、脚本错误或自动化程序缺陷导致的“误删表”（DROP TABLE）或误清空表（TRUNCATE TABLE）等逻辑错误仍然无法杜绝。而一旦此类故障在生产业务系统发生，尤其是在账务和交易类核心系统中，可能会导致业务中断、资金损失、声誉受损乃至引发系统性风险，其后果不堪设想。
因此，在误删表发生时如何快速地恢复数据，尽量缩短业务的中断时间（RTO），同时要数据丢失尽可能少（RPO），需要制定可靠和快速的恢复方案。通常而言，基于数据库自身的技术和特性，误删表恢复主要有以下几种方案：
-
闪回或回收站功能：这是一种逻辑层面的快速恢复技术。它并非真正地物理删除对象，而是将其“隐藏”或保留数据的历史版本，允许在特定时间窗口内快速“撤销”删除操作。此方法恢复速度最快，对系统影响最小，是应对逻辑错误的首选。
-
备份恢复：最传统最可靠的恢复方案，通过将数据库恢复到误删除操作之前的时间点，跳过执行副操作的时间点对外提供服务。这种方案最为成熟可靠，但通常耗时较长，并且恢复过程中对现有业务系统会有影响。
-
延迟库：通过建立一个与主库保持特定时间延迟的备用数据库，当主库发生误操作时，可以在该错误传播到备库之前，跳过误操作时点的事务利用延迟库对外提供服务，或许利用延迟库获取正确的数据恢复到主库。
下文将整理Oracle、DB2、MySQL、PostgreSQL等传统数据库和GaussDB、GoldenDB、TiDB、OceanBase等国产数据库在上述三种方案中各自实现方法。只对各个方案的功能实现，不会深入具体方案的实现技术细节。
闪回与回收站功能其核心思想是提供一种机制，允许用户在执行破坏性操作（如DROP TABLE）后，能够快速、简便地将数据或对象恢复到操作前的状态。闪回技术大多依赖于数据库的多版本并发控制（MVCC）机制或专门的撤销（UNDO）数据：
-
基于MVCC/UNDO的闪回：当数据被修改或删除时，旧版本的数据并不会立即被物理清除，而是被保留在特定的存储空间中。闪回查询（Flashback Query）正是利用这些保留的旧版本数据，查询某个过去时间点的数据状态；闪回表（Flashback Table）则是利用UNDO日志中的信息，生成反向的DML操作，从而将表恢复到指定时间点。
-
回收站机制：当用户执行DROP TABLE或TRUNCATE TABLE命令时，数据库系统不会立即释放表所占用的存储空间，而是将该表及其关联对象（如索引、约束等）重命名并移入一个逻辑上的“回收站”区域。这些对象对用户来说是不可见的，但其物理数据仍然存在。用户可以通过特定的命令（如FLASHBACK TABLE … TO BEFORE DROP）将表从回收站中“捞回”，这个过程本质上只是一个快速的元数据操作，因此速度极快。回收站中的对象会根据设定的保留策略或在空间压力下被系统自动清除（PURGE）。
1）Oracle数据库闪回技术
Oracle数据库支持回收站（Recyclebin）、闪回表 (Flashback Table)和闪回查询 (Flashback Query)功能。执行DROP TABLE时，表被重命名为一个系统生成的唯一名称（如BIN$…）并放入回收站，使用FLASHBACK TABLE <table_name> TO BEFORE DROP恢复。
2）DB2数据库闪回技术
DB2没有提供与Oracle类似的通用闪回或回收站功能
3）MySQL数据库
原生MySQL并未提供内置的闪回或回收站功能。一旦DROP TABLE或TRUNCATE TABLE被提交，数据和定义就从逻辑层面消失了。
4）PostgreSQL数据库
与MySQL类似，PostgreSQL内核本身也没有提供原生的闪回表或回收站功能。DROP TABLE是一个不可逆的操作。
5）GaussDB（for openGauss）数据库
GaussDB支持回收站功能，通过GUC参数enable_recyclebin开启。当DROP TABLE或TRUNCATE TABLE执行时，表对象被移入回收站，而非物理删除。恢复时使用FLASHBACK TABLE … TO BEFORE DROP/TRUNCATE命令 。回收站中对象的保留时间由recyclebin_retention_time参数控制，默认为15分钟。
6）GoldenDB数据库
GoldenDB在V6版本开始支持闪回功能，可以将表数据恢复到特定的时间点。作为分布式数据库，其闪回功能需要确保在所有数据分片上的一致性。
7）TiDB数据库
TiDB提供了FLASHBACK TABLE <table_name> TO TIMESTAMP …命令。执行时，TiDB会利用指定时间戳之前最新的数据版本来恢复表。从v4.0版本开始，FLASHBACK TABLE可以恢复被DROP或TRUNCATE的表。另外FLASHBACK CLUSTER，甚至支持对整个集群进行闪回。
8）OceanBase数据库
OceanBase内置了回收站功能。当DROP TABLE或DROP DATABASE时，对象会被放入回收站。可以通过FLASHBACK TABLE/DATABASE … TO BEFORE DROP来恢复。另外也支持SELECT … AS OF SCN/TIMESTAMP …语法，允许查询特定时间点的快照数据。
使用闪回或回收站受限于回收站空间的大小以及undo空间历史数据的保留时间，如果其所占用的空间被后续操作重用或者超过UNDO数据保留时长，则数据无法恢复。
PITR的备份恢复能力是数据库的基本功能，基于全量备份以及增量备份和数据库日志，恢复到指定的恢复时间点完成数据恢复。在实际的备份架构中常用的有两种架构：
-
一阶段备份直接备份到集中备份：通过备份软件或原生备份工具，直接将备份数据流写入到后端的集中备份存储介质中，恢复时需要从集中备份存储中读取备份数据（全量、增量、归档日志）来恢复服务器。这种备份恢复架构节省了过度资源，但是恢复性能严重依赖于后端存储的读取性能和网络带宽。
-
二阶段备份将备份到本地NAS或OBS再到集中备份：数据库将备份数据先写入本地高性能存储设备，再通过集中备份软件备份到备份存储保存。在恢复时，优先从本地备份存储设备恢复，极大的缩短了恢复时间。当然缺点是需要额外的本地备份存储资源，成本更高，一般为数据库大小的2~3倍空间。
据悉某国有大行11月份误删表的恢复就是采用从集中备份去恢复数据，结果花了两三天时间才完全恢复数据以恢复业务。
延迟库的本质是一个数据异步复制的备库，备库在接收到主库传来的变更日志后，并不会立即应用到备机，而是会等待一个预设的时间之后再执行。这样，如果主库在T0时刻发生了一次误删表操作，这个DROP TABLE语句产生的日志会很快传到备库，但备库会等到T0 + 2小时这个时刻才会去执行它。在这个时间窗口内，可以将备库设置为只读状态，导出误删表的数据并恢复到主库；也可以在备库跳过误删表的事务，将业务切换到延迟库运行。
1）Oracle数据库Data Guard延迟
在Oracle Data Guard环境中，可以通过在备库端设置LOG_ARCHIVE_DEST_n参数的DELAY属性来实现备库延迟回放。
2）DB2的HADR模式
DB2的HADR（高可用性灾难恢复）功能主要设计用于高可用，其同步模式（SYNC, NEARSYNC, ASYNC, SUPERASYNC）关注的是日志发送和写入磁盘的时间，但并未提供一个内建的、简单的参数来配置日志应用的延迟。
3）MySQL延迟从库
MySQL主从复制支持延迟功能，通过在从库上执行CHANGE MASTER TO MASTER_DELAY = N;（N为秒数）即可设置。从库的I/O线程会正常接收并写入Relay Log，但SQL线程会等待N秒后再执行。
4）PostgreSQL流复制备库
PostgreSQL的流复制备库可以通过在备库设置recovery_min_apply_delay参数来实现延迟应用。
5）GaussDB（for openGauss）数据库
GaussDB也支持recovery_min_apply_delay参数来实现备库的延迟应用，其配置方式和行为与PostgreSQL一样。需要注意的是当synchronous_commit设置为remote_apply时，主库的事务提交会等待备库应用完成，这会把延迟时间叠加到主库的响应时间上。
6）GoldenDB数据库
GoldenDB数据库支持基于MySQL原生的MASTER_DELAY延迟复制功能，同时在V6版本的DRSP架构下，支持分布式架构下集群级别的延迟阈值配置。
7）TiDB数据库
在TiCDC同步任务中设置sync-delay参数，使下游集群延迟应用变更。
8）OceanBase数据库
OceanBase 的物理备库（租户级别）支持延迟同步，可通过配置ls_gc_delay_time控制日志延迟删除，或直接暂停备租户的日志同步实现延迟。
从备库延迟回放的功能上看，大部分国产数据库已经具备了延迟备库的基本功能，通过设置一定的阈值延迟回放是，当主库在逻辑上误删库或误删数据时，通过延迟备库可以找到这部分数据。现在通用的做法是在备库将这部分数据导出并恢复到主库，从故障恢复的RTO角度而言，这个导出导入的时间依旧是要花费一定的时间。更具延迟库效果的是在延迟备库跳过误操作的事务ID，将延迟库临时作为主库对外提供服务，从而能够快速恢复业务。因此延迟备库方案具备以下特征：
-
在生产集群之外的一套独立的管理集群，通过主备复制延迟控制延迟库的延迟阈值，在主库故障时具备单独接管的能力。从资源部署的角度而言，至少需要1个副本的服务器资源。
-
延迟备库的延迟阈值可灵活调整，并且在主库出现逻辑上误操作时候，在备库可以通过跳过误操作事务ID的方式，来保证数据的完整性，快速恢复业务。
-
延迟备库因为数据库日志在备机长时间未回放，在备库会存在存储空间膨胀。
-
主备库需要严格依赖统一的时钟源NTP，否则会出现延迟阈值设置不精确的问题。
整体上而言，延迟库方案从架构设计、功能实现以及故障应急的流程上而言相对难度较大。不过作为一个通用性的需求场景，国产数据库厂商也朝这个方向努力。据了解GoldenDB数据库最新版本的DRSP方案已经具备延迟库的功能，GaussDB在505版本还不具备，未来版本也在规划这一部分功能需求。其它数据库厂商也在往这一块发力，毕竟是一个通用性的需求。
对比了Oracle、DB2、MySQL、PostgreSQL等传统数据库和GaussDB、GoldenDB、TiDB、OceanBase等国产数据库在闪回/回收站、备份恢复和延迟备库三种数据恢复的方案，如下所示：
|
数据库
|
闪回/回收站
|
备份恢复
|
延迟备库
|
|---|---|---|---|
|
Oracle
|
支持
|
RMAN工具
|
设置LOG_ARCHIVE_DEST_n参数
|
|
DB2
|
不支持
|
Backup和Restore，支持前向和后向恢复
|
不支持
|
|
MySQL
|
不支持
|
xtrabackup备份恢复
|
从库设置MASTER_DELAY
|
|
PostgreSQL
|
不支持
|
基于WAL的PITR
|
从库设置recovery_min_apply_delay
|
|
GaussDB
|
支持
|
gs_roach工具
|
从库设置recovery_min_apply_delay
|
|
GoldenDB
|
支持，默认未开启
|
分布式场景的一致性备份
|
从库设置MASTER_DELAY或基于DRSP的备集群延迟复制方案
|
|
TiDB
|
支持
|
基于快照备份，实现PITR
|
TiCDC同步任务中设置sync-delay参数
|
|
OceanBase
|
支持
|
租户级备份
|
无参数控制
|
在误删表这一类逻辑删除的故障场景下，在数据库层主要围绕闪回或回收站、备份恢复来实现的。闪回或回收站是在发现故障后分钟级响应，利用回收站功能实现数据的快速恢复；备份恢复是数据库最终的兜底方案，其能够保证最终数据的完整性和可靠性，但是恢复本身耗时很长，恢复的时效性最终影响了业务RTO时间。延迟备库是一种资源和恢复时效上的折中，虽然各类数据库具备备库延迟值的配置，但是国产数据库目前还不具备将延迟备库在故障时作为主库的产品能力，无论是在应急处置的流程上还是数据恢复的时效性上，因此在现阶段还不成熟，并不具备实施的可行性。
参考资料：