tidb-数据误删恢复的几种方式

一、背景

在日常的操作中难免有些误操作，那这时候有什么办法，不通的数据库有不同的办法，多数是用备份恢复，还有一些其他特有的方法，如mysql的binlog,那么tidb有什么特有的方法呢，下面来介绍下

二、环境准备

# 建表和准备数据
create table recover_test(id int(10));
insert into recover_test values(1),(2),(3),(4);

# 查看gc相关参数，tikv_gc_life_time，tikv_gc_safe_point，tikv_gc_safe_point
select * from mysql.tidb where VARIABLE_NAME like '%gc%';
tikv_gc_life_time

三、恢复方法

1.flashback

描述： DROP 或 TRUNCATE 删除的表是在 tikv_gc_safe_point 时间之后，都能用 FLASHBACK TABLE 语法来恢复。
注意： 下游是mysql的时候会因为mysql不支持该语法造成cdc或者binlog同步失败

# 清空表
truncate table recover_test;
# 恢复表数据
flashback table recover_test to recover_test_1;
# 删除表
drop table recover_test;
# 恢复表
flashback table recover_test;
# 第二次恢复表，可以看到下面有个报错，因为 FLASHBACK 所恢复表的 table ID 还是被删除表的 table ID，而 TiDB 要求所有还存在的表 table ID 必须全局唯一，所以删除一次表，不能恢复两次
flashback table recover_test to recover_test_2;
ERROR 1050 (42S01): Table 'recover_test' already been flashback to 'recover_test', can't be flashback repeatedly
 

2.recover

描述： DROP 删除的表是在 tikv_gc_safe_point 时间之后，用recover 语法来恢复。
注意： 下游是mysql的时候会因为mysql不支持该语法造成cdc或者binlog同步失败

# 删除表
drop table recover_test;
# 恢复表
recover table recover_test;

3.dumpling --snapshot

描述： dml更新表或者drop,truncaate是在 tikv_gc_safe_point 时间之后，用snapshot语法来恢复。

# 删除数据
delete from recover_test where id = 3;
# 导出快照时间，注意该时间要大于tikv_gc_safe_point
dumpling --snapshot "2022-06-02 17:12:45"
# 导入导出的文件
lighting ...

4.select into outfile

描述： dml更新表或者drop,truncaate是在 tikv_gc_safe_point 时间之后，用snapshot语法来恢复。

# 删除数据
delete from recover_test where id = 3;
# 设置快照时间
set @@tidb_snapshot="2022-06-02 15:50:26";
# select into outfile导出，注意，连接的是哪个tidb,导出文件的位置就在哪个tidb上
select * from recover_test into outfile '/data/tidb/a.txt';
# 导入数据
load data ... 

5.历史备份恢复

lighting
br