本文档详细介绍TiDB单表恢复与库级恢复，包括恢复基础、恢复类型、恢复原理、生产环境规划、实施方案、实战案例等内容。风哥教程参考TiDB官方文档BR工具相关内容，适合DBA在日常维护TiDB数据库时参考。更多视频教程www.fgedu.net.cn
Part01-基础概念与理论知识
1.1 恢复基础
数据恢复是指将备份的数据还原到数据库中的过程，是保证数据安全的重要手段。
- 恢复的定义：恢复是指将备份的数据还原到数据库中的过程，以恢复数据库到某个时间点的状态。
- 恢复的重要性：
- 数据安全：防止数据丢失
- 业务连续性：确保业务在故障后快速恢复
- 数据迁移：支持数据迁移和升级
- 数据验证：验证备份的有效性
- 恢复的类型：
- 全量恢复：恢复整个数据库
- 增量恢复：恢复自上次备份以来的变化
- 单表恢复：恢复单个表的数据
- 库级恢复：恢复单个数据库的数据
- 针对性：根据需要恢复特定的数据
- 灵活性：可以选择恢复的范围和时间点
- 效率性：相比全库恢复，单表或库级恢复更高效
- 安全性：减少对其他数据的影响
1.2 恢复类型
风哥提示：
根据恢复的范围和方式，TiDB的恢复可以分为多种类型。
1.2.1 按恢复范围分类
## 1. 全量恢复
– 定义：恢复整个数据库集群的数据
– 特点：
– 恢复范围大
– 恢复时间长
– 影响整个集群
– 适用场景：
– 集群灾难恢复
– 数据迁移
– 系统重建
## 2. 库级恢复
– 定义：恢复单个数据库的数据
– 特点：
– 恢复范围中等
– 恢复时间适中
– 影响单个数据库
– 适用场景：
– 数据库误操作
– 数据库损坏
– 数据库迁移
## 3. 单表恢复
– 定义：恢复单个表的数据
– 特点：
– 恢复范围小
– 恢复时间短
– 影响单个表
– 适用场景：
– 表误操作
– 表数据损坏
– 表结构变更
## 4. 行级恢复
– 定义：恢复表中的特定行数据
– 特点：
– 恢复范围最小
– 恢复时间最短
– 影响最小
– 适用场景：
– 单行数据误操作
– 单行数据损坏
1.2.2 按恢复方式分类
## 1. 物理恢复
– 定义：使用物理备份文件进行恢复
– 特点：
– 恢复速度快
– 适合大规模数据
– 对数据库版本有要求
– 工具：
– TiDB BR工具
## 2. 逻辑恢复
– 定义：使用逻辑备份文件进行恢复
– 特点：
– 跨版本兼容
– 恢复速度慢
– 适合小数据量
– 工具：
– TiDB Dumpling工具
– MySQL客户端（导入SQL文件）
## 3. 增量恢复
– 定义：恢复自上次备份以来的变化
– 特点：
– 恢复时间点精确
– 依赖全量备份
– 恢复过程复杂
– 工具：
– TiDB BR工具
## 4. 实时恢复
– 定义：使用实时同步工具进行恢复
– 特点：
– 近实时恢复
– 低延迟
– 持续同步
– 工具：
– TiCDC
1.3 恢复原理
TiDB的恢复原理基于备份文件和恢复工具的工作机制。
1.3.1 单表恢复原理
## 1. 基于BR工具的单表恢复学习交流加群风哥QQ113257174
– 原理：
– BR工具支持按表进行备份和恢复
– 使用`–table`参数指定要恢复的表
– 从备份文件中提取指定表的数据
– 将数据恢复到目标表
– 特点：
– 支持物理备份和恢复
– 恢复速度快
– 适合大规模数据
– 对表结构有要求
## 2. 基于Dumpling的单表恢复
– 原理：
– Dumpling工具支持按表导出数据
– 使用`-t`参数指定要导出的表
– 生成SQL或CSV文件
– 使用MySQL客户端导入数据
– 特点：
– 跨版本兼容
– 恢复速度慢
– 适合小数据量
– 表结构可以不同
## 3. 基于TiCDC的单表恢复
– 原理：
– TiCDC实时同步表数据
– 支持按表过滤
– 近实时恢复
– 持续同步
– 特点：
– 低延迟
– 近实时恢复
– 适合灾备场景
– 配置复杂
1.3.2 库级恢复原理
## 1. 基于BR工具的库级恢复
– 原理：
– BR工具支持按数据库进行备份和恢复
– 使用`–db`参数指定要恢复的数据库
– 从备份文件中提取指定数据库的数据
– 将数据恢复到目标数据库
– 特点：
– 支持物理备份和恢复
– 恢复速度快
– 适合大规模数据
– 对数据库结构有要求
## 2. 基于Dumpling的库级恢复
– 原理：
– Dumpling工具支持按数据库导出数据
– 使用`-B`参数指定要导出的数据库
– 生成SQL或CSV文件
– 使用MySQL客户端导入数据
– 特点：
– 跨版本兼容
– 恢复速度慢
– 适合小数据量
– 数据库结构可以不同
## 3. 基于TiCDC的库级恢复
– 原理：
– TiCDC实时同步数据库数据
– 支持按数据库过滤
– 近实时恢复
– 持续同步
– 特点：
– 低延迟
– 近实时恢复
– 适合灾备场景
– 配置复杂
Part02-生产环境规划与建议
2.1 恢复规划
2.1.1 恢复需求分析
## 1. 业务需求分析
– 业务重要性：评估数据对业务的重要程度
– RTO (Recovery Time Objective)：恢复时间目标
– RPO (Recovery Point Objective)：恢复点目标
– 业务连续性：确保业务连续运行的要求
## 2. 数据量分析
– 数据库大小：评估数据库的总大小
– 表大小：评估单个表的大小
– 数据变更率：评估数据变更的频率和数量
– 恢复时间窗口：可用的恢复时间
## 3. 系统环境分析
– 硬件资源：CPU、内存、存储、网络
– 软件版本：TiDB版本，恢复工具版本
– 部署架构：集群规模，节点分布
– 网络环境：网络带宽，延迟
## 4. 风险分析
– 数据丢失风险：评估数据丢失的可能性和影响
– 恢复失败风险：评估恢复失败的可能性和影响
– 业务中断风险：评估恢复过程中业务中断的影响
– 性能影响风险：评估恢复过程对系统性能的影响
2.1.2 恢复策略制定
## 1. 恢复工具选择
– 物理恢复：
– 工具：TiDB BR工具
– 适用场景：大规模数据，快速恢复
– 优势：恢复速度快，适合大规模数据
– 劣势：对版本有要求，表结构必须一致
– 逻辑恢复：
– 工具：TiDB Dumpling工具
– 适用场景：小数据量，跨版本恢复
– 优势：跨版本兼容，表结构可以不同
– 劣势：恢复速度慢，适合小数据量
– 实时恢复：
– 工具：TiCDC
– 适用场景：灾备，近实时恢复
– 优势：低延迟，近实时恢复
– 劣势：配置复杂，需要额外资源
## 2. 恢复流程制定
– 准备阶段：
– 确认恢复需求
– 准备恢复环境
– 选择恢复工具
– 获取备份文件
– 执行阶段：
– 停止相关服务
– 执行恢复操作
– 监控恢复过程
– 验证恢复结果
– 完成阶段：
– 启动相关服务
– 验证业务功能
– 记录恢复过程
– 清理恢复环境
## 3. 恢复时间预估
– 全量恢复：
– 时间：数小时到数天
– 因素：数据量，存储性能，网络带宽
– 库级恢复：
– 时间：数十分钟到数小时
– 因素：数据库大小，存储性能，网络带宽
– 单表恢复：
– 时间：数分钟到数十分钟
– 因素：表大小，存储性能，网络带宽
## 4. 恢复验证策略
– 数据完整性验证：
– 检查数据量
– 检查关键数据
– 检查数据一致性
– 业务功能验证：
– 测试业务查询
– 测试业务操作
– 测试业务流程
– 性能验证：
– 检查系统性能
– 检查查询性能
– 检查写入性能
2.2 恢复工具
## 1. TiDB BR工具
– 简介：
– TiDB Backup & Restore工具
– 支持物理备份和恢复
– 支持全量和增量备份
– 支持按库和表备份恢复
– 安装：
[root@fgedu.net.cn ~]# tiup install br
– 常用命令：
– 备份全库：tiup br backup full
– 备份指定库：tiup br backup db
– 备份指定表：tiup br backup table
– 恢复全库：tiup br restore full
– 恢复指定库：tiup br restore db
– 恢复指定表：tiup br restore table
– 优势：
– 恢复速度快
– 适合大规模数据
– 支持增量恢复
– 劣势：
– 对版本有要求
– 表结构必须一致
– 配置复杂
## 2. TiDB Dumpling工具
– 简介：
– TiDB逻辑备份工具
– 支持导出SQL或CSV文件
– 支持按库和表导出
– 跨版本兼容
– 安装：
[root@fgedu.net.cn ~]# tiup install dumpling
– 常用命令：
– 导出全库：tiup dumpling
– 导出指定库：tiup dumpling -B dbname
– 导出指定表：tiup dumpling -t dbname.table
– 导入数据：mysql -h host -P port -u user -p < dump.sql - 优势： - 跨版本兼容 - 表结构可以不同 - 配置简单 - 劣势： - 恢复速度慢 - 适合小数据量 - 不支持增量恢复
## 3. TiCDC工具 - 简介： - TiDB Change Data Capture - 实时同步数据 - 支持按库和表过滤 - 近实时恢复 - 安装： [root@fgedu.net.cn ~]# tiup
install cdc - 常用命令： - 创建同步任务：tiup cdc cli changefeed create - 查看同步任务：tiup cdc cli changefeed list - 管理同步任务：tiup
cdc cli changefeed pause/resume - 优势： - 低延迟 - 近实时恢复 - 持续同步 - 劣势： - 配置复杂 - 需要额外资源 - 不支持历史数据恢复
2.3 恢复策略
## 1. 全量恢复策略
– 适用场景：
– 集群灾难恢复
– 数据迁移
– 系统重建
– 恢复步骤：
1. 停止应用服务
2. 清理目标集群
3. 执行全量恢复
4. 验证恢复结果
5. 启动应用服务
– 注意事项：
– 确保目标集群已准备就绪
– 确保备份文件完整
– 监控恢复过程
– 验证恢复结果
## 2. 库级恢复策略
– 适用场景：
– 数据库误操作
– 数据库损坏
– 数据库迁移
– 恢复步骤：
1. 停止相关应用服务
2. 备份目标数据库（可选）
3. 执行库级恢复
4. 验证恢复结果
5. 启动相关应用服务
– 注意事项：
– 确保目标数据库已准备就绪
– 确保备份文件完整
– 避免影响其他数据库
– 验证恢复结果
## 3. 单表恢复策略
– 适用场景：
– 表误操作
– 表数据损坏
– 表结构变更
– 恢复步骤：
1. 停止相关应用服务
2. 备份目标表（可选）
3. 执行单表恢复
4. 验证恢复结果
5. 启动相关应用服务
– 注意事项：
– 确保目标表已准备就绪
– 确保备份文件完整
– 避免影响其他表
– 验证恢复结果
## 4. 增量恢复策略
– 适用场景：
– 数据丢失后的恢复
– 时间点恢复
– 灾备演练
– 恢复步骤：
1. 停止应用服务
2. 执行全量恢复
3. 执行增量恢复
4. 验证恢复结果
5. 启动应用服务
– 注意事项：
– 确保备份链完整
– 确保时间点正确
– 监控恢复过程
– 验证恢复结果
Part03-生产环境项目实施方案
3.1 单表恢复
3.1.1 使用BR工具进行单表恢复
## 1. 准备工作
– 检查TiDB集群状态：
[root@fgedu.net.cn ~]# tiup cluster status fgedu-tidb
输出：
Cluster type: tidb
Cluster name: fgedu-tidb
Cluster version: v7.5.0
Deploy user: tidb
SSH type: builtin
ID Role Host Ports Status Data Dir Deploy Dir
— —- —- —– —— ——– ———-
192.168.1.1:9093 alertmanager 192.168.1.1 9093/9094 Up /tidb/fgdata/alertmanager-9093
/tidb/app/alertmanager-9093
192.168.1.1:3000 grafana 192.168.1.1 3000 Up /tidb/fgdata/grafana-3000 /tidb/app/grafana-3000
192.168.1.1:2379 pd 192.168.1.1 2379/2380 Up /tidb/fgdata/pd-2379 /tidb/app/pd-2379
192.168.1.2:2379 pd 192.168.1.2 2379/2380 Up /tidb/fgdata/pd-2379 /tidb/app/pd-2379
192.168.1.3:2379 pd 192.168.1.3 2379/2380 Up /tidb/fgdata/pd-2379 /tidb/app/pd-2379
192.168.1.4:4000 tidb 192.168.1.4 4000/10080 Up /tidb/fgdata/tidb-4000 /tidb/app/tidb-4000
192.168.1.5:4000 tidb 192.168.1.5 4000/10080 Up /tidb/fgdata/tidb-4000 /tidb/app/tidb-4000
192.168.1.6:20160 tikv 192.168.1.6 20160/20180 Up /tidb/fgdata/tikv-20160 /tidb/app/tikv-20160
192.168.1.7:20160 tikv 192.168.1.7 20160/20180 Up /tidb/fgdata/tikv-20160 /tidb/app/tikv-20160
192.168.1.8:20160 tikv 192.168.1.8 20160/20180 Up /tidb/fgdata/tikv-20160 /tidb/app/tikv-20160
– 准备备份文件：
[root@fgedu.net.cn ~]# ls -la /tidb/backup/full/20240101-000000/
输出：
total 48567890
drwxr-xr-x 2 tidb tidb 4096 Jan 1 00:30 .
drwxr-xr-x 3 tidb tidb 4096 Jan 1 00:00 ..
-rw-r–r– 1 tidb tidb 12345 Jan 1 00:00 backupmeta
-rw-r–r– 1 tidb tidb 4972589012 Jan 1 00:30 data.0
– 停止相关应用服务：
[root@fgedu.net.cn ~]# systemctl stop app.service
## 2. 执行单表恢复
– 执行单表恢复命令：
[root@fgedu.net.cn ~]# tiup br restore table –pd “192.168.1.1:2379” –storage
“local:///tidb/backup/full/20240101-000000” –db fgedudb –table fgedu_users
输出：
[2024-01-04 10:00:00] [info] [restore.go:123] [“table restore start”]
[2024-01-04 10:00:05] [info] [restore.go:145] [“restore meta done”]
[2024-01-04 10:05:15] [info] [restore.go:167] [“restore data done”]
[2024-01-04 10:05:20] [info] [restore.go:189] [“table restore success”]
## 3. 验证恢复结果
– 检查表数据：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “SELECT COUNT(*) FROM fgedudb.fgedu_users;”
输出：
+———-+
| COUNT(*) |
+———-+
| 10000 |
+———-+
– 检查表结构：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “DESCRIBE fgedudb.fgedu_users;”
– 检查关键数据：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “SELECT * FROM fgedudb.fgedu_users ORDER BY
id DESC LIMIT 10;”
## 4. 启动应用服务
– 启动应用服务：
[root@fgedu.net.cn ~]# systemctl start app.service
3.1.2 使用Dumpling工具进行单表恢复
## 1. 准备工作
– 安装Dumpling工具：
[root@fgedu.net.cn ~]# tiup install dumpling
– 导出单表数据：
[root@fgedu.net.cn ~]# tiup dumpling -h 192.168.1.1 -P 4000 -u fgedu -p -B fgedudb -t fgedu_users -o
/tidb/backup/dump/
输出：
[2024-01-01 00:00:00] [info] [dumpling.go:123] [“dump start”]
[2024-01-01 00:00:05] [info] [dumpling.go:145] [“dump schema done”]
[2024-01-01 00:01:15] [info] [dumpling.go:167] [“dump data done”]
[2024-01-01 00:01:20] [info] [dumpling.go:189] [“dump success”]
– 查看导出文件：
[root@fgedu.net.cn ~]# ls -la /tidb/backup/dump/
输出：
total 123456
drwxr-xr-x 2 root root 4096 Jan 1 00:01 .
drwxr-xr-x 3 root root 4096 Jan 1 00:00 ..
-rw-r–r– 1 root root 12345 Jan 1 00:00 fgedudb.fgedu_users-schema.sql
-rw-r–r– 1 root root 12345678 Jan 1 00:01 fgedudb.fgedu_users.sql
– 停止相关应用服务：
[root@fgedu.net.cn ~]# systemctl stop app.service
## 2. 执行单表恢复
– 导入单表数据：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p fgedudb <
/tidb/backup/dump/fgedudb.fgedu_users.sql 输出： (无错误输出表示导入成功) ## 3. 验证恢复结果 - 检查表数据： [root@fgedu.net.cn ~]#
mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e "SELECT COUNT(*) FROM fgedudb.fgedu_users;" 输出： +----------+ |
COUNT(*) | +----------+ | 10000 | +----------+ - 检查表结构： [root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000
-u fgedu -p -e "DESCRIBE fgedudb.fgedu_users;" - 检查关键数据： [root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000
-u fgedu -p -e "SELECT * FROM fgedudb.fgedu_users ORDER BY id DESC LIMIT 10;" ## 4. 启动应用服务 - 启动应用服务：
[root@fgedu.net.cn ~]# systemctl start app.service
3.2 库级恢复
3.2.1 使用BR工具进行库级恢复
## 1. 准备工作
– 检查TiDB集群状态：
[root@fgedu.net.cn ~]# tiup cluster status fgedu-tidb
– 准备备份文件：
[root@fgedu.net.cn ~]# ls -la /tidb/backup/full/20240101-000000/
– 停止相关应用服务：
[root@fgedu.net.cn ~]# systemctl stop app.service
## 2. 执行库级恢复
– 执行库级恢复命令：
[root@fgedu.net.cn ~]# tiup br restore db –pd “192.168.1.1:2379” –storage
“local:///tidb/backup/full/20240101-000000” –db fgedudb
输出：
[2024-01-04 10:00:00] [info] [restore.go:123] [“db restore start”]
[2024-01-04 10:00:05] [info] [restore.go:145] [“restore meta done”]
[2024-01-04 10:15:15] [info] [restore.go:167] [“restore data done”]
[2024-01-04 10:15:20] [info] [restore.go:189] [“db restore success”]
## 3. 验证恢复结果
– 检查数据库：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “SHOW DATABASES;”
输出：
+——————–+
| Database |
+——————–+
| fgedudb |
| information_schema |
| mysql |
| performance_schema |
| sys |
+——————–+
– 检查表：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “SHOW TABLES IN fgedudb;”
– 检查数据量：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “SELECT COUNT(*) FROM
fgedudb.fgedu_users;”
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “SELECT COUNT(*) FROM
fgedudb.fgedu_orders;”
## 4. 启动应用服务
– 启动应用服务：
[root@fgedu.net.cn ~]# systemctl start app.service
3.2.2 使用Dumpling工具进行库级恢复
## 1. 准备工作
– 安装Dumpling工具：
[root@fgedu.net.cn ~]# tiup install dumpling
– 导出数据库数据：
[root@fgedu.net.cn ~]# tiup dumpling -h 192.168.1.1 -P 4000 -u fgedu -p -B fgedudb -o /tidb/backup/dump/
输出：
[2024-01-01 00:00:00] [info] [dumpling.go:123] [“dump start”]
[2024-01-01 00:00:05] [info] [dumpling.go:145] [“dump schema done”]
[2024-01-01 00:10:15] [info] [dumpling.go:167] [“dump data done”]
[2024-01-01 00:10:20] [info] [dumpling.go:189] [“dump success”]
– 查看导出文件：
[root@fgedu.net.cn ~]# ls -la /tidb/backup/dump/
输出：
total 2345678
drwxr-xr-x 2 root root 4096 Jan 1 00:10 .
drwxr-xr-x 3 root root 4096 Jan 1 00:00 ..
-rw-r–r– 1 root root 1234 Jan 1 00:00 fgedudb-schema-create.sql
-rw-r–r– 1 root root 12345 Jan 1 00:00 fgedudb.fgedu_users-schema.sql
-rw-r–r– 1 root root 12345678 Jan 1 00:05 fgedudb.fgedu_users.sql
-rw-r–r– 1 root root 12345 Jan 1 00:05 fgedudb.fgedu_orders-schema.sql
-rw-r–r– 1 root root 23456789 Jan 1 00:10 fgedudb.fgedu_orders.sql
– 停止相关应用服务：
[root@fgedu.net.cn ~]# systemctl stop app.service
## 2. 执行库级恢复
– 创建数据库（如果不存在）：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e “CREATE DATABASE IF NOT EXISTS
fgedudb;”
– 导入数据库结构：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p fgedudb <
/tidb/backup/dump/fgedudb-schema-create.sql - 导入表结构： [root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000
-u fgedu -p fgedudb < /tidb/backup/dump/fgedudb.fgedu_users-schema.sql [root@fgedu.net.cn ~]# mysql -h
192.168.1.1 -P 4000 -u fgedu -p fgedudb < /tidb/backup/dump/fgedudb.fgedu_orders-schema.sql - 导入表数据：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p fgedudb <
/tidb/backup/dump/fgedudb.fgedu_users.sql [root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu
-p fgedudb < /tidb/backup/dump/fgedudb.fgedu_orders.sql 输出： (无错误输出表示导入成功) ## 3. 验证恢复结果 - 检查数据库：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e "SHOW DATABASES;" - 检查表：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p -e "SHOW TABLES IN fgedudb;" - 检查数据量：
[root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u fgedu -p
-e "SELECT COUNT(*) FROM fgedudb.fgedu_users;" [root@fgedu.net.cn ~]# mysql -h 192.168.1.1 -P 4000 -u
fgedu -p -e "SELECT COUNT(*) FROM fgedudb.fgedu_orders;" ## 4. 启动应用服务 - 启动应用服务： [root@fgedu.net.cn ~]#
systemctl start app.service
3.3 恢复自动化
3.3.1 恢复脚本创建
## 1. 单表恢复脚本
– 创建单表恢复脚本：
[root@fgedu.net.cn ~]# cat > restore_table.sh << 'EOF' #!/bin/bash # restore_table.sh #
from:www.itpux.com.qq113257174.wx:itpux-com # web: `http://www.fgedu.net.cn` # 检查参数 if [ $# -ne 4 ]; then
echo "Usage: $0
