前言

这几天在整理我的文件的时候，发现这篇半年前写的备份恢复的笔记。

这个笔记是参照官方文档做的实践，并结合了自己的一些理解写出来的，感觉还有点用处，另外也是怕存到本地文件丢了，所以还是发一下吧，供各位参考。

操作

本次所有步骤都在tidb用户下操作

本次操作集群结构：

Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.8.0/tiup-cluster display tidb-test Cluster type: tidb Cluster name: tidb-test Cluster version: v5.1.0 Deploy user: tidb SSH type: builtin Dashboard URL: http://172.24.74.69:2379/dashboard ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 172.24.74.68:9093 alertmanager 172.24.74.68 9093/9094 linux/x86_64 Up /tidb/tidb-data/alertmanager-9093 /tidb/tidb-deploy/alertmanager-9093 172.24.74.68:3000 grafana 172.24.74.68 3000 linux/x86_64 Up - /tidb/tidb-deploy/grafana-3000 172.24.74.67:2379 pd 172.24.74.67 2379/2380 linux/x86_64 Up|L /tidb/tidb-data/pd-2379 /tidb/tidb-deploy/pd-2379 172.24.74.68:2379 pd 172.24.74.68 2379/2380 linux/x86_64 Up /tidb/tidb-data/pd-2379 /tidb/tidb-deploy/pd-2379 172.24.74.69:2379 pd 172.24.74.69 2379/2380 linux/x86_64 Up|UI /tidb/tidb-data/pd-2379 /tidb/tidb-deploy/pd-2379 172.24.74.67:9090 prometheus 172.24.74.67 9090 linux/x86_64 Up /tidb/tidb-data/prometheus-9090 /tidb/tidb-deploy/prometheus-9090 172.24.74.67:4000 tidb 172.24.74.67 4000/10080 linux/x86_64 Up - /tidb/tidb-deploy/tidb-4000 172.24.74.68:4000 tidb 172.24.74.68 4000/10080 linux/x86_64 Up - /tidb/tidb-deploy/tidb-4000 172.24.74.69:4000 tidb 172.24.74.69 4000/10080 linux/x86_64 Up - /tidb/tidb-deploy/tidb-4000 172.24.74.67:20160 tikv 172.24.74.67 20160/20180 linux/x86_64 Up /tidb/tidb-data/tikv-20160 /tidb/tidb-deploy/tikv-20160 172.24.74.68:20160 tikv 172.24.74.68 20160/20180 linux/x86_64 Up /tidb/tidb-data/tikv-20160 /tidb/tidb-deploy/tikv-20160 172.24.74.69:20160 tikv 172.24.74.69 20160/20180 linux/x86_64 Up /tidb/tidb-data/tikv-20160 /tidb/tidb-deploy/tikv-20160 Total nodes: 12

部署工具包

工具包建议部署在PD节点

工具包中包含的工具：br dumpling mydumper pd-tso-bench sync_diff_inspector tidb-lightning tidb-lightning-ctl tikv-importer

本次步骤在tidb用户下的home目录执行

下载工具包

wget https://download.pingcap.org/tidb-toolkit-v5.0.1-linux-amd64.tar.gz

解压工具包，得到工具包目录

tar xvf tidb-toolkit-v5.0.1-linux-amd64.tar.gz

将工具包目录配置到环境变量

打开环境变量配置文件

vi ~/.bash_profile

追加以下内容

export PATH=/home/tidb/tidb-toolkit-v5.0.1-linux-amd64/bin:$PATH

保存后source命令使环境变量生效

source ~/.bash_profile

BR

备份

BR工具备份推荐使用共享存储，本次条件有限，使用本地存储操作

全库备份

在所有tikv节点创建备份目录并修改备份目录权限

mkdir /tidb/backup/20211214 chmod 755 /tidb/backup/20211214

在br工具包的安装节点，如本次的pd节点172.24.74.67，执行备份命令：

br backup full --pd "172.24.74.67:2379" --storage "local:///tidb/backup/20211214" --ratelimit 120 --log-file backupfull.log参数解释： --pd : 任意pd节点id --storage ：tikv节点的备份目录，需保证目录存在且为空 ，否则会报错 --ratelimit ： 带宽限速，120即为120M/S --log-file ： 备份日志存放文件 备份成功会得到`Full backup success summary`字样的提示

单库备份

在所有tikv节点创建备份目录，并修改目录权限

mkdir /tidb/backup/20211214-yyh chmod 755 /tidb/backup/20211214-yyh

开始备份，指定库备份较全库备份略有变化

br backup db --pd "172.24.74.67:2379" --db yyh --storage "local:///tidb/backup/20211214-yyh" --ratelimit 120 --log-file backupdb.log参数解释： --db ：备份的库 备份成功会得到`Full backup success summary`字样的提示

单表备份

在所有tikv节点创建备份目录，并修改目录权限

mkdir /tidb/backup/20211214-test2 chmod 755 /tidb/backup/20211214-test2

开始备份，指定库备份较全库备份略有变化

br backup table --pd "172.24.74.67:2379" --db yhh --table test1 --storage "local:///tidb/backup/20211214-test2" --ratelimit 120 --log-file backuptable.log参数解释： --table ：备份的表 备份成功会得到`Full backup success summary`字样的提示

恢复

本次条件有限，使用本地存储操作，恢复时需将所有节点的备份合并，再分发到所有节点的备份目录中

最优方案是共享存储，可不用合并分发的操作直接恢复，因为备份时就备到了同一个目录中

将本次需要恢复的所有节点上的备份合并到一个节点上

本例为全备份（单库单表恢复同样操作），合并到172.24.74.67

cd /tidb/backup/20211214 scp 172.24.74.68:/tidb/backup/20211214/* . scp 172.24.74.69:/tidb/backup/20211214/* .

将合并好的备份分发到所有节点原有位置

scp * 172.24.74.68:/tidb/backup/20211214/. scp * 172.24.74.69:/tidb/backup/20211214/.

个人实验结论：

只要备份中包含需要恢复的对象，就可以选择全部恢复或者只恢复部分，如：备份为全备，可只恢复yyh单库，或者yhh库的test单表

且无论备份命令是full、db、table，只要保证备份集中有自己需要的对象，恢复时均可用full、db、table中的任意一个命令恢复的对象现在的状态必须是不存在或者空的，否则会跳过，切最终结果会提示恢复错误。

举个栗子：t1被删了，t2被清空了，t3还有数据，这种情况只会恢复t1和t2，t3会跳过

全库恢复

执行恢复命令

br restore full --pd "172.24.74.67:2379" --storage "local:///tidb/backup/20211214" --log-file restoredb.log

恢复成功会得到Full backup success summary字样的提示，随后可进入mysql环境验证恢复情况

单库恢复

执行恢复命令

br restore db --pd "172.24.74.67:2379" --db yyh --storage "local:///tidb/backup/20211214-yyh" --log-file restoredb.log

参数说明： --db 参数只能指定一个库

恢复成功会得到Full backup success summary字样的提示，随后可进入mysql环境验证恢复情况

单表恢复

执行恢复命令

br restore table --pd "172.24.74.67:2379" --db yhh --table test2 --storage "local:///tidb/backup/20211214-test2" --log-file restoredb.log

参数说明： --db --table 只能指定到一个库的一个表

恢复成功会得到Full backup success summary字样的提示，随后可进入mysql环境验证恢复情况

指定对象恢复

执行恢复命令，本方法时full恢复命令的专有方法，db和table都没有

例1： 恢复yyh库中的所有表 br restore full --pd "172.24.74.67:2379" --filter yyh.* --storage "local:///tidb/backup/20211214" --log-file restoredb.log 例2： 恢复所有y开头的库中的test1表 br restore full --pd "172.24.74.67:2379" --filter y*.test1 --storage "local:///tidb/backup/20211214" --log-file restoredb.log

恢复成功会得到Full backup success summary字样的提示，随后可进入mysql环境验证恢复情况

Dumpling & Lightning

Dumpling:把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式，用于逻辑全量备份

Lightning:是一个将全量数据高速导入到 TiDB 集群的工具，可导入 Dumpling、CSV 或 Amazon Aurora Parquet 输出格式的数据源

Dumpling

全量导出

dumpling \ -u root \ -p root123\ -P 4000 \ -h 172.24.74.67 \ --filetype sql \ -t 8 \ -o /tidb/backup/dumpbak \ -r 200000 \ -F 256MiB

参数说明：

-h、-P、-u 、-p分别代表连接tidb-server（任意一个）的地址、端口、用户、密码。如果没有密码，就去掉-p参数

-o 用于选择存储导出文件的目录。可以是任意层级的目录，只要有上层目录的操作权限就行

-t 用于指定导出的线程数。增加线程数会增加 Dumpling 并发度提高导出速度，但也会加大数据库内存消耗，因此不宜设置过大。一般不超过 64。

-r用于指定单个文件的最大行数，指定该参数后 Dumpling 会开启表内并发加速导出，同时减少内存使用。

-F 选项用于指定单个文件的最大大小，单位为 MiB，可接受类似 5GiB 或 8KB 的输入。如果你想使用 TiDB Lightning 将该文件加载到 TiDB 实例中，建议将 -F 选项的值保持在 256 MiB 或以下

--filetype 参数默认是sql，可选参数值 sql，csv。如导出sql可不指定本参数

带sql条件导出

dumpling \ -u root \ -p root123\ -P 4000 \ -h 172.24.74.67 \ --filetype csv \ -t 8 \ -o /tidb/backup/dumpbak \ -r 200000 \ -F 256MiB \ --sql select * from yyh.test1 where id < 1000

参数说明

--sql中写查询语句，本次只导出你的查询结果。本参数只适用于导出csv格式

带筛选条件导出

使用 --where 选项筛选数据

dumpling \ -u root \ -p root123\ -P 4000 \ -h 172.24.74.67 \ --filetype sql \ -t 8 \ -o /tidb/backup/dumpbak \ -r 200000 \ -F 256MiB \ --where id < 1000

参数说明： --where本次条件即为导出所有表id<1000的值，本参数不可与--sql 同时使用，导出格式可选sql和csv

使用 --filter 选项筛选数据

dumpling \ -u root \ -p root123\ -P 4000 \ -h 172.24.74.67 \ --filetype sql \ -t 8 \ -o /tidb/backup/dumpbak \ -r 200000 \ -F 256MiB \ --filter "yyh.*" \ --filter "*.test1"

参数说明： --filter 筛选需要的库或表，上例表示导出yyh库下所有表和所有库中的test1表。可以和--where共用

使用 -B 或 -T 选项筛选数据

dumpling \ -u root \ -p root123\ -P 4000 \ -h 172.24.74.67 \ --filetype sql \ -t 8 \ -o /tidb/backup/dumpbak \ -r 200000 \ -F 256MiB \ -B "yyh" \ -B "yhh" dumpling \ -u root \ -p root123\ -P 4000 \ -h 172.24.74.67 \ --filetype sql \ -t 8 \ -o /tidb/backup/dumpbak \ -r 200000 \ -F 256MiB \ -T "yhh.test1" \ -T "yyh.test1" \ --where "id < 100"

参数说明： -B指定表导出的库，如需导出多个库，则指定多个-B参数。参数值不支持模糊匹配，如yy*-T 指定导出的表，如需导出多个表，则指定多个-T参数。同样不支持模糊匹配 -B 、 -T、--filter 三个参数互斥，无法同时使用，即只能选择其中一个参数使用；三个参数都可与--where共用

导出历史数据快照

dumpling \ -u root \ -p root123\ -P 4000 \ -h 172.24.74.67 \ --filetype sql \ -t 8 \ -o /tidb/backup/dumpbak \ -r 200000 \ -F 256MiB \ --snapshot "2021-12-15 19:03:45"

参数说明：

--snapshot 可导出历史版本数据，如上方指定的时间，还可以使用TSO（SHOW MASTER STATUS 输出的 Position 字段），但前提条件是历史版本还没有GC。可以和其他参数共用。

Lightning

Lightning工具建议独立部署，原因是比较吃硬件资源，混合部署容易影响其他业务

操作步骤

配置tidb-lightning.toml

恢复前请确认好各参数，特别是backend参数

[lightning] # 转换数据并发数，默认为逻辑cpu数量，独立部署可不用设置本参数，混合部署建议设置为逻辑cpu的75% # region-concurrency = # 日志 level = "info" file = "tidb-lightning.log" [tikv-importer] # 选择使用的 local 后端模式 ,需根据需求调整模式 # 也可在命令行用参数方式指定，如：tidb-lightning -d /tmp/data --backend tidbbackend= "local" # 设置排序的键值对的临时存放地址，目标路径需要是一个有权限的空目录 sorted-kv-dir = "/tmp/sorted-kv-dir" [checkpoint] # 启用断点续传，导入时会记录当前进度 enable = true # 断点存储方式，可选本地文件（file）或者mysql服务器（mysql），这里以本地文件作为参数 # driver = "file" # 断点的存放位置 # # 若 driver = "file"，此参数为断点信息存放的文件路径。 # 如果不设置该参数则默认为 `/tmp/CHECKPOINT_SCHEMA.pb` # # 若 driver = "mysql"，此参数为数据库连接参数 (DSN)，格式为“用户:密码@tcp(地址:端口)/”。 # 默认会重用 [tidb] 设置目标数据库来存储断点。 # 为避免加重目标集群的压力，建议另外使用一个兼容 MySQL 的数据库服务器。 dsn = "/tmp/tidb_lightning_checkpoint.pb" [mydumper] # 源数据目录。 data-source-dir = "/tidb/backup/dumpbak" # 配置通配符规则，默认规则会过滤 mysql、sys、INFORMATION_SCHEMA、PERFORMANCE_SCHEMA、METRICS_SCHEMA、INSPECTION_SCHEMA 系统数据库下的所有表 # 也可通过命令行参数方式指定，如：tidb-lightning -f yyh.* -f test*.test1 -d /tmp/data --backend tidb filter = [yyh.*,test*.test1] [tidb] # 目标集群的信息 host = "172.24.74.67" port = 4000 user = "root" password = "root123" # 表架构信息在从 TiDB 的“状态端口”获取。 status-port = 10080 # 集群 pd 的地址 pd-addr = "172.24.74.67:2379"

后端模式对比：

后端Local-backendImporter-backendTiDB-backend速度快 (~500 GB/小时)快 (~400 GB/小时)慢 (~50 GB/小时)资源使用率高高低占用网络带宽高中低导入时是否满足 ACID否否是目标表必须为空必须为空可以不为空额外组件无tikv-importer无支持 TiDB 集群版本>= v4.0.0全部全部是否影响 TiDB 对外提供服务是是否

执行恢复

nohup tidb-lightning -config tidb-lightning.toml > nohup.out &

导入完毕后，TiDB Lightning 会自动退出。若导入成功，日志的最后一行会显示 tidb lightning exit。

导入中断切回正常模式

lightning导入前会将tikv集群切换为导入模式，优化写入效率并停止自动压缩，集群将无法正常对外提供服务。如果导入异常中断不会自动切回正常模式，此时需要手动操作切回

tidb-lightning-ctl --switch-mode=normal

切回正常模式后再去排查并解决异常，后续导入如需断点续传请参考下一步操作

断点续传的控制

若 tidb-lightning 因不可恢复的错误而退出（例如数据出错），重启时不会使用断点，而是直接报错离开。为保证已导入的数据安全，这些错误必须先解决掉才能继续。使用 tidb-lightning-ctl 工具可以标示已经恢复。

--checkpoint-error-destroytidb-lightning-ctl --checkpoint-error-destroy=`schema`.`table`

该命令会让失败的表从头开始整个导入过程。选项中的架构和表名必须以反引号 (`) 包裹，而且区分大小写。

如果导入 `schema`.`table` 这个表曾经出错，这条命令会：

从目标数据库移除 (DROP) 这个表，清除已导入的数据。

将断点重设到“未开始”的状态。

如果 `schema`.`table` 没有出错，则无操作。

传入 "all" 会对所有表进行上述操作。这是最方便、安全但保守的断点错误解决方法：

tidb-lightning-ctl --checkpoint-error-destroy=all--checkpoint-error-ignoretidb-lightning-ctl --checkpoint-error-ignore=`schema`.`table` && tidb-lightning-ctl --checkpoint-error-ignore=all

如果导入 `schema`.`table` 这个表曾经出错，这条命令会清除出错状态，如同没事发生过一样。传入 "all" 会对所有表进行上述操作。

注意：

除非确定错误可以忽略，否则不要使用这个选项。如果错误是真实的话，可能会导致数据不完全。启用校验和 (CHECKSUM) 可以防止数据出错被忽略。

--checkpoint-removetidb-lightning-ctl --checkpoint-remove=`schema`.`table` && tidb-lightning-ctl --checkpoint-remove=all

无论是否有出错，把表的断点清除。