一、先从最省事的开始，GC时间内的恢复

简单解释下，TiDB有个参数，tidb_gc_life_time ，一般默认是10分钟。建议适当加大。

查询方式

select @@tidb_gc_life_time;

再不行就看grafana里，tikv-details> gc 有个TiKV Auto GC SafePoint，只要是在这个时间之后的，都可以通过下面3个方式恢复。

1.1 表的数据量很小，通过工具导出

set @@tidb_snapshot="2023-11-12 10:53:26";

导出，这个就看你的工具了，一般的Navicat就挺好用的。

导入一样用工具，记得建个新表。

1.2 表的数据量中等，百万级别，考虑一下使用loaddata

loaddata导出

set @@tidb_snapshot="2023-11-12 10:53:26"; SELECT * FROM t10 INTO OUTFILE /tmp/t10.csv FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY " LINES TERMINATED BY \r\n ;

loaddata导入

set session tidb_batch_commit=50000; LOAD DATA LOCAL INFILE /tmp/t10.csv INTO TABLE t10_bak FIELDS TERMINATED BY , ENCLOSED BY \" LINES TERMINATED BY \r\n (id, name, id2);

留个疑问，仔细查下tidb_batch_commit参数，你会发现官方不推荐设置这个参数，这个会破坏事务一致性的，为什么我要在导入前加入这个参数呢？

加戏——指定列导入

LOAD DATA LOCAL INFILE /tmp/t14.csv INTO TABLE t14 FIELDS TERMINATED BY , ENCLOSED BY \" LINES TERMINATED BY \r\n (@C1,@C2,@C3,@C4,@C5 ) set row_id=@C1, name=@C2, id=@C4, c=@C5;

非常规使用tidb，就造就了一些场景需要指定列导入：

a.表中存在虚拟列

b.想在导入阶段对值做些处理

1.3 表数据很大，千万级以上，建议用Dumpling  +  Lightning

dumpling导出

官方参数就挺好用，搬运一下

./dumpling -u root -P 4900 -h 127.0.0.1 -o /tmp/test \ --snapshot "2023-12-05 15:12:45" \ --filetype csv -F 100MiB \ -T test.t4

Lightning导入

也是从官方参数就挺好用，搬运一下。

建议使用tidb模式，可以满足大部分场景的需求了。如果确实速度太慢，表太大，可以优先调整参数region-concurrency。

[lightning] # 日志 level = "info" file = "/tmp/tidb-lightning.log" check-requirements = true [mydumper] data-source-dir = "/tmp/test" [tikv-importer] backend = "tidb" [tidb] host = "127.0.0.1" port = 4000 user = "root" password = "" log-level = "error"

./tidb-lightning  --config /tmp/lightning.toml

导出常见报错如下，请检查gc时间，数据被gc了，再次强调默认数据库的tidb_gc_life_time时间为10m。

请使用异机恢复方式。

create dumper failed: fail to set snapshot for tidb, please set --consistency=none/--consistency=lock or fix snapshot problem: Error 8055: snapshot is older than GC safe point 2023-12-05 14:27:33.218 +0800 CST

导入有同名表需要注意下，直接导入是不会报错的，会清理数据，建议手动改下导出的文件，换个表名。最好是空库导入

以下是一些的尝试，验证了一下骚操作的可行性

1.尝试直接insert，报错明显，语法不通。

MySQL [test]> insert into t5 select * from t4 as of timestamp 2023-12-06 08:45:26; ERROR 8135 (HY000): can not set different time in the as of

2.设置了快照时间insert，报错表不在，第一反应，不是刚建的新表，为啥不存在，仔细一想，报错没啥问题，历史时间点下，数据库是没有这个表的。

MySQL [test]> set @@tidb_snapshot=2023-12-06 08:45:26; Query OK, 0 rows affected (0.00 sec) MySQL [test]> insert into t5 select * from t4 ; ERROR 1146 (42S02): Table test.t5 doesnt exist

3.假使我有预感，建一个空表一直放着，再搞呢。还是报错了，这个报错信息就比较直接了，不能在快照下对数据做修改。

MySQL [test]> set @@tidb_snapshot=2023-12-06 09:13:00; Query OK, 0 rows affected (0.01 sec) MySQL [test]> insert into t5 select * from t4 ; ERROR 1105 (HY000): can not execute write statement when tidb_snapshot is set

已经踩过了，看到的人就不要再踩了。老老实实正规操作。

1.4 本地恢复drop table、truncate table

a. 本地恢复drop table、truncate table

Flashback table

truncate需要把现有表换名

b. 6.5以上版本又多了两个功能

整个集群闪退Flashback cluster

单个database级别drop闪回

flashback database database_name to database_name;

有没有发现一个小技巧，tidb在6.5是不支持直接rename database，但是可以通过flashback database换名。

二、gc时间外，异机恢复

没有全备和没有日志的就别妄想恢复了，该醒醒了，赶紧配吧，别等真的需要再搞。如果真的有方法，偷偷告诉我，我想学。

2.1 binlog恢复

当集群配置有pump和drainer的时候，就可以使用全备（一般都是dumpling）+增量的binlog，配置有全备和全备时间点后的增量binlog日志。

全备恢复工具lighting，不在赘述。

增量恢复工具reparo配置文件，注意stop-tso可以写时间的。

data-dir = "/tidb-data4/binlog" log-level = "info" start-tso = "2023-12-02 15:04:05" stop-datetime = "2023-12-02 15:04:05" dest-type = "mysql" safe-mode = false [[replicate-do-table]] db-name ="test" tbl-name = "t4" [dest-db] host = "127.0.0.1" port = 4000 user = "root" password = "xxxxxxxxxxx"./reparo -config reparo.toml

再稍微说下reparo，binlog解析工具，不仅可以做增量恢复，还可以dest-type = "print"导出sql文本。比如只是误删一部分数据，就可以解析问题时间段日志就行了。

2.2 br full + br log

br用于全备的库，要求还是比较多的，一般要挂cos或nas，不然备到本地，恢复的时候还需要手动整合到一起。

br相当于binglog组件虽然要求多，但是真的快，毕竟是相当于物理级别的cp，记忆犹新一个大库dump一天搞不完，用br搞2个多小时，当然要cos或者nas也足够快。

br log是pitr，是直接从kv取的增量变化，这个也是需要挂cos或nas用于存储。

br恢复的命令比较简单了，把全备恢复和增量恢复整合在了一起，很友好。

tiup br restore point \ --pd="10.3.72.75:2979" \ --full-backup-storage=/tidbbackup/brfull/ \ --storage "/tidbbackup/brlog/"

简单看下效果

tiup is checking updates for component br ... Starting component `br`: /home/db/tidb/.tiup/components/br/v6.5.3/br restore point --pd=10.3.72.75:2979 --full-backup-storage=/tidbbackup/brfull/ --storage /tidbbackup/brlog/ Detail BR log in /tmp/br.log.2023-12-05T10.29.16+0800 Full Restore <-------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00% [2023/12/05 10:29:23.647 +08:00] [INFO] [collector.go:73] ["Full Restore success summary"] [total-ranges=29] [ranges-succeed=29] [ranges-failed=0] [split-region=655.559µs] [restore-ranges=12] [total-take=7.100235857s] [total-kv-size=504.4MB] [average-speed=71.04MB/s] [restore-data-size(after-compressed)=27.13MB] [Size=27131118] [BackupTS=446101705187131404] [RestoreTS=446101810752520193] [total-kv=254138] Restore Meta Files <-------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00% Restore KV Files <---------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00% [2023/12/05 10:29:24.702 +08:00] [INFO] [collector.go:73] ["restore log success summary"] [total-take=1.054945723s] [restore-from=446101705187131404] [restore-to=446101733590433793] [restore-from="2023-12-05 10:22:34.968 +0800"] [restore-to="2023-12-05 10:24:23.318 +0800"] [total-kv-count=12] [total-size=1.947kB] [average-speed=1.846kB/s]

可以看到先做的是Full Restore 全备，后面做的restore log增量恢复。

总结一下：

所有恢复前提，就是你要了解数据库的恢复的前提条件具不具备，比如说gc设置1天，一天做一次全备不做增备，能恢复什么时间点的数据。

为了确保今后在遇到误操作删数据问题时能够迅速、有效地解决，请重视备份。 本篇也是想总结下各个恢复手段，希望能帮助到大家！

如果有什么不对，还请多多指正！

作者介绍：Soysauce520，来自神州数码钛合金战队，是一支致力于为企业提供分布式数据库TiDB整体解决方案的专业技术团队。团队成员拥有丰富的数据库从业背景，全部拥有TiDB高级资格证书，并活跃于TiDB开源社区，是官方认证合作伙伴。目前已为10+客户提供了专业的TiDB交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。