一、先从最省事的开始，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' doesn't 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交付服务，涵盖金融、证券、物流、电力、政府、零售等重点行业。