数据库｜恢复的方式多种多样，总有一款适合你

本文主要是介绍数据库｜恢复的方式多种多样，总有一款适合你，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

相信大家在日常的工作中都有遇见过需要恢复数据库的情况，那么在工作中我们要如何确保高效迅速地恢复数据呢？

本篇文章为大家带了几种详细的恢复方式！

一、GC时间内的恢复

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

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

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

二、gc时间外，异机恢复

2.1 binlog恢复

2.2 br full + br log

三、总结

一、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，就造就了一些场景需要指定列导入：

表中存在虚拟列
想在导入阶段对值做些处理

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增量恢复。