TiDB 备份恢复方式你知多少？

作者： tplinux 原文来源：https://tidb.net/blog/682145ee

背景

学习一款数据库，要学会备份和恢复。备份是一个严谨的工作，作为一个 dba，掌握数据库备份、恢复的各种手段。

下面让我们一起来看看 TiDB 的备份恢复有那些手段吧。

基于 MVCC 的恢复方式

相关原理已经在上一篇文章写过了，这里就不在做过多的描述了。

TiDB 用什么保证备份的一致性？

简单的回顾一下，TiDB 的 TiKV 里面的 MVCC 的格式是基于时间戳的。

(key-versionT（SO 全局唯一递增时间戳)–>vlues）

会有定时 GC 来清理过期的版本 (数据)。

下面的工具都是基于 MVCC 的方式，假设数据以及被 GC 清理掉了，那么数据就不能恢复过来。

第一款工具 snapshot

TiDB 自带工具，可以针对当前会话读到指定的历史版本。

UPDATE mysql.tidb SET VARIABLE_VALUE = ‘80h’ WHERE VARIABLE_NAME = ‘tikv_gc_life_time’;

# 更改 GC 时间

sql=“SET SESSION tidb_snapshot = ‘415599012634951683’”。

# 跳转 GC 时间

# 此处有个操作视频传到百度云盘中

链接：https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ

提取码：anxp 工具说明：只能恢复 dml，不能恢复 ddl。

第二款工具 Recover

TiDB 自带工具，可以针对 drop table 语句进行恢复。

drop table t2;# 删除表

recover table t2; # 恢复表

# 此处有个操作视频传到百度云盘中

链接：https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ

提取码：anxp

工具限制：只能恢复 drop table 的操作，不能恢复 truncate table，delete 操作。未来可能会被 Flashback 取代。

第三款工具 Flashback

TiDB 自带工具，可以针对 truncate 操作。

工具限制：只能恢复 truncate，drop 等 ddl 的操作，没有办法恢复 dml 操作。

# 此处有个操作视频传到百度云盘中 链接：https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ

提取码：anxp

工具总结：

1. 如果使用上述三种工具 要保证误操作的范围在 GC 清理之前。如果数据以及被 GC 清理了，则无法使用。

2. 目前推荐大家要了解掌握上述三种工具的基础的操作，避免在真正的误操作发生的时候，能快速恢复。

基于文件的恢复方式

所谓基于文件的恢复方式，指备份的结果集存储在文件中，例如全备份，增量备份等。

第一款工具 mydumper/l oader

TiDB 官方推荐的备份工具 mydumper ，经过官方的修改和优化。

在备份的时候，去除了 FTWRL 锁等待，而且支持并行备份，大幅提升了备份效率。

./bin/mydumper -h 127.0.0.1 -u root -P 4000 # 执行备份

./bin/loader -d 备份路径 -h 127.0.0.1 -u root -P 4000 # 恢复备份

# 此处有个操作视频传到百度云盘中

链接：https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ

提取码：anxp

如果大家嫌弃导入慢，可以用 TiDB 官方推荐的生态工具 TiDB Lightning 。能给提升 TiDB 的导入效率。

第二款工具 TiDB binlog

TiDB binlog，可以用于增量恢复 TiDB 集群。

还可以适用于 TiDB 同步下游 TiDB 集群、MySQL、Kafka。

TiDB binlog 分为 2 个组件 Pump 和 Drainer 两个组件，先给大家介绍一下。

Pump 组件：

1. 用于实时记录 TiDB 产生的 Binlog。

2. 将 binlog 按照时间提交时间进行排序。

3. 在提个给 Drainer 组件进行消费。

Drainer 组件：

1. 收集各个 Pump 中收集的 Binlog 进行归并。

2. 将 Binlog 转行成 SQL 或者指定格式的数据。

# 感觉好像 MySQL 的 io thread 和 sql thread。

# 此处有个操作视频传到百度云盘中

链接：https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ

提取码：anxp 增量恢复的方法我已经传到视频中了，大家可以看看。

第三款工具 BR

TiDB 最近提供的一款分布式备份恢复工具 BR，可以针对 TiDB 集群进行备份和恢复。

使用限制：

1. 只支持 TiDBv3.1 及以上版本

2. 目前需要 nfs 作为共享磁盘

# 此处有个操作视频传到百度云盘中

链接：https://pan.baidu.com/s/1QDmFk-9-N-gcNMJr5ZqXzQ

提取码：anxp

备份原理：

1. 从 pd 中获取当前的 TSO 作为备份快照的时间点。

2. 当前集群的 TiKV 节点信息。

下面的 br 在执行的日志。也可以大概的看出相关的内容。

[2020/04/04 17:16:37.610 +08:00] [INFO] [log-file=/tmp/br.log.2020-04-04T17:16:37+08:00] [pd=”[10.206.0.3:2379]“] [storage=local:///export/backup] [timeago=0s]

# 说明备份日志输出位置，pd 节点，备份结果集

[2020/04/04 17:16:37.612 +08:00] [INFO] [base_client.go:226] [“[pd] update member urls”] [old-urls=”[http://10.206.0.3:2379]“] [new-urls=”[http://10.206.0.16:2379,http://10.206.0.3:2379,http://10.206.0.6:2379]“]

# 获取整个 pd 集群

[2020/04/04 17:16:37.622 +08:00] [INFO] [ddl.go:321] [“[ddl] start DDL”] [ID=b823eca8-e3e5-4969-a67f-5ff3b6210d1d] [runWorker=false]

[2020/04/04 17:16:37.647 +08:00] [INFO] [domain.go:144] [“full load InfoSchema success”] [usedSchemaVersion=0] [neededSchemaVersion=87] [“start time”=5.263313ms]

[2020/04/04 17:16:37.648 +08:00] [INFO] [domain.go:368] [“full load and reset schema validator”]

# 获取对应的表结构

[2020/04/04 17:16:37.650 +08:00] [INFO] [client.go:112] [“backup encode timestamp”] [BackupTS=415758233800278018]

# 获取备份的时间点 tso

[2020/04/04 17:16:37.657 +08:00] [INFO] [client.go:222] [“change table AutoIncID”] [db=tian] [table=t1] [AutoIncID=2000001]

# 开始执行 db 为 tian,table 为 t1 的备份

此时根据备份子命令，会有两种备份逻辑：

• 全量备份：BR 遍历全部库表，并且根据每一张表构建需要备份的 KV Range

• 单表备份：BR 根据该表构建需要备份的 KV Range

最后，BR 将需要备份的 KV Range 收集后，构造完整的备份请求分发给集群内的 TiKV 节点。

https://pingcap.com/docs-cn/dev/reference/tools/br/br/

这段话来自官方文档，我简单的描述，大家会更好的理解。

1. 每个 Region 都有 Region Leader，每个 Region Leader 都分布在不同的 TiKV 上。

2. BR 首先知道备份哪些 KV Range，然后把备份的 KV Range 收集后。构建一个完整的备份请求，下发给所有的 TiKV 节点。

3. TiKV 收到这些备份请求，开始执行备份命令。

备份文件类型

sst文件：存储TiKV备份下来的数据信息。
backupmeta文件：存储本次备份的元信息。

实际操作

实验环境：腾讯云

机器配置：4C8G

数据大小：57G

备份耗时：大于 9 分钟小于 10 分钟

TIKV 数量：3 个

备份大小：50G（官方好像没做压缩啊，期待 GR 版本在此处能够完善改进）

[2020/04/04 19:17:30.808 +08:00] [INFO]

[“Full backup Success summary: total backup ranges: 15,

total success: 15, total failed: 0, total take(s): 544.32, total kv: 285323076,

total size(MB): 58774.74, avg speed(MB/s): 107.98”]

[“backup checksum”=1m51.113016071s]

[“backup fast checksum”=59.215757ms]

[“backup total regions”=699]

备份时性能影响：

br 备份影响相对较小，因为备份指令都下发到不同的 TiKV 节点，TiKV 会承担备份压力。

总结

相信大家看了这么多内容，大家应该会 TiDB 备份恢复方式有了一定的了解。

可以对集群设置 N 个小时的 GC 超时时间：没超过这 N 个小时的误操作，可以通过基于 MVCC 的方式进行恢复。可以根据不同的语句来，选择不同的恢复方式。如果超过了 N 个小时，可以选择 binlog 的方式进行增量恢复。

mydumper 和 br 工具，我个人感觉更适合

1. 灾难式恢复（整个集群都挂了，例如所有磁盘坏了，机柜宕机。但 TiDB 本身就是分布式，所以这个可能性不大。

2. 构建新的集群，做集群之间的同步。

安利一下：官方推出了增量同步工具 CDC ，一句话描述他的有点：基于“redo log” 同步。