【TiDB原理与实战详解】3、 集群升级和逻辑备份恢复~学不会? 不存在的!

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: TiDB集群可通过打补丁和版本升级来维护。打补丁针对特定组件(如TiDB或TiKV)进行,而版本升级包括不停机升级和停机升级两种方式,前者会重启部分组件。升级前需更新tiup工具并调整拓扑配置,确保集群健康。TiDB的数据备份与恢复依赖于Dumpling和TiDB Lightning工具,前者负责数据导出,后者用于数据导入。导出时推荐使用小文件和多线程以提升效率,并可通过多种参数控制导出细节。恢复时需注意备份目录与存储节点分离,并可通过配置文件控制导入过程,支持断点续传及错误处理策略。此外,4.0及以上版本支持库表过滤功能,便于灵活管理数据导入。

六、TiDB Cluster 升级

1、打补丁

# tidb 补丁打法
tiup  cluster patch  集群名称  /tmp/***.tar.gz  -R tidb

# tikv 补丁打法
tiup  cluster patch  集群名称  /tmp/***.tar.gz  -R tikv

。。。。

2、TiDB Cluster 版本升级

升级分为停机升级和不停机升级,但是不停机升级也会重启一些组件

# 首先将 tiup 工具升级到最新版本(建议高于1.4)
tiup update --self
# --self //表示将 tiup 升级到最新版本
# --all  //表示将所有组件升级到稳定版本

# 升级 cluster 组件
tiup update  cluster:v1.8.1  //修改为自己需要的版本

# 修改tiup cluster 拓扑配置文件  //因为老版本和新版可能存在差异 详解见官方文档
tiup cluster edit-config test

# 检查健康状态(regions)
tiup cluster check test  --cluster  # 检查时会有些fail和Warn可以选择性优化

# 不停机升级(必要时也会重启一些组件)
tiup cluster upgrade test  v5.3.0

注意:
滚动升级会逐个升级所有的组件。升级 TiKV 期间,会逐个将 TiKV 上的所有 leader 切走再停止该 TiKV 实例。默认超时时间为 5 分钟(300 秒),超时后会直接停止该实例。
如果不希望驱逐 leader,而希望快速升级集群至新版本,可以在上述命令中指定 --force,该方式会造成性能抖动,不会造成数据损失。
如果希望保持性能稳定,则需要保证 TiKV 上的所有 leader 驱逐完成后再停止该 TiKV 实例,可以指定 --transfer-timeout 为一个更大的值,如 --transfer-timeout 3600,单位为秒。

# 停机升级
tiup cluster stop test # 先停止集群
tiup cluster upgrade test v5.3.0  --offline  # 执行升级
tiup cluster start test # 启动集群

# 查看集群状态
tiup cluster display test

七、逻辑备份恢复

使用 Dumpling/TiDB Lightning 对 TiDB 进行全量备份与恢复。增量备份和同步可使用 TiDB Binlog。在这个备份恢复过程中,会用到下面的工具:
Dumpling:从 TiDB 导出数据
TiDB Lightning:导入数据到 TiDB

Dumpling/TiDB Lightning 全量备份恢复最佳实践

为了快速地备份恢复数据(特别是数据量巨大的库),可以参考以下建议:

- 导出来的数据文件应当尽可能的小,可以通过设置选项 `-F` 来控制导出来的文件大小。如果后续使用 TiDB Lightning 对备份文件进行恢复,建议把 `dumpling` -F 选项的值设置为 `256m`。
- 如果导出的表中有些表的行数非常多,可以通过设置选项 `-r` 来开启表内并发。

dumpling 默认不导出系统表

1、TiDB 备份数据

安装dumpling 可以通过 TiDB Release 查看当前已发布版本。

# tiup 工具安装
tiup install dumpling

# 下载包安装
wget  https://download.pingcap.org/tidb-toolkit-v5.3.0-linux-amd64.tar.gz

# 解压
tar xf tidb-toolkit-v5.3.0-linux-amd64.tar.gz

最低使用权限

SELECT
RELOAD
LOCK TABLES
REPLICATION CLIENT
PROCESS

参数详解

-h、-P、-u 分别代表地址、端口、用户。如果需要密码验证,可以使用 -p $YOUR_SECRET_PASSWORD 将密码传给 Dumpling。
-o 用于选择存储导出文件的目录,支持本地文件路径或外部存储 URL 格式。
-t 用于指定导出的线程数。增加线程数会增加 Dumpling 并发度提高导出速度,但也会加大数据库内存消耗,因此不宜设置过大。一般不超过 64。
-r 用于指定单个文件的最大行数,指定该参数后 Dumpling 会开启表内并发加速导出,同时减少内存使用。当上游为 TiDB 且版本为 v3.0 或更新版本时,该参数大于 0 表示使用 TiDB region 信息划分表内并发,具体取值将不再生效。
-F 选项用于指定单个文件的最大大小,单位为 MiB,可接受类似 5GiB 或 8KB 的输入。如果你想使用 TiDB Lightning 将该文件加载到 TiDB 实例中,建议将 -F 选项的值保持在 256 MiB 或以下。    
--sql 选项仅仅可用于导出 CSV 的场景。
-B 备份的库
-d 不保存数据


如果导出的单表大小超过 10 GB,强烈建议使用 -r 和 -F 参数。

导出sql文件 (如/tmp/test目录有相同名字的内容将会被覆盖)

# 多表导出
/root/tidb-toolkit-v5.3.0-linux-amd64/bin/dumpling \
-h 127.0.0.1 \
-P 4000 \
-u root \
-p'123.00' \
-t 32 \
-F 256m \
-T test.t1 \
-T test.t2  \
-o /tmp/test

# 指定库导出
/root/tidb-toolkit-v5.3.0-linux-amd64/bin/dumpling \
-h 127.0.0.1 \
-P 4000 \
-u root \
-p'123.00' \
-t 32 \
-F 256m \
-B test \
-o /tmp/test

导出CSV文件

假如导出数据的格式是 CSV(使用 --filetype csv 即可导出 CSV 文件),还可以使用 --sql <SQL> 导出指定 SQL 选择出来的记录,例如,导出 test.sbtest1 中所有 id < 100 的记录:

/root/tidb-toolkit-v5.3.0-linux-amd64/bin/dumpling \
-h 127.0.0.1 \
-P 4000 \
-u root \
-p'123.00' \
-o /tmp/test_t1 \
--filetype csv \
--sql 'select * from `test`.`t1` where id < 100'

2、TiDB 恢复数据

注意:备份所在目录和kv(存储节点)不能在同一磁盘上,否则无法通过检查

进入bin目录

cd /root/tidb-toolkit-v5.0.1-linux-amd64/bin/

编辑导入配置信息

vim  tidb-lightning.toml
[lightning]
# 日志
level = "info"
file = "tidb-lightning.log"

[tikv-importer]
# 选择使用的 local 后端
backend = "local"
# 设置排序的键值对的临时存放地址,目标路径需要是一个空目录
sorted-kv-dir = "/tmp/tmp"

[mydumper]
# mydumper 源数据目录(备份所在文件)
data-source-dir = "/boot/test/"

[tidb]
# 目标集群连接信息
host = "10.10.8.107"
port = 4000
user = "root"
password='123.00'

# 表架构信息在从 TiDB 的“状态端口”获取。
status-port = 10080
# 集群 pd 的地址
pd-addr = "10.10.8.107:2379"

指定配置文件导入

    这里推荐使用 nohup  的方式后台执行恢复操作
# 使用脚本运行命令
vim test_lightning.sh
#! /bin/bash
/root/tidb-toolkit-v5.3.0-linux-amd64/bin/tidb-lightning -config    /root/tidb-toolkit-v5.3.0-linux-amd64/bin/tidb-lightning.toml  

# 运行脚本
nohup  sh test_lightning.sh >test_lightning.log &

断点续传

1、配置文件配置参数

vim  tidb-lightning.toml 
[checkpoint]
enable = true

# 断点信息存储
driver = 'file' # 如果不设置该参数则默认为 `/tmp/CHECKPOINT_SCHEMA.pb`

# 导入成功后是否保留断点。默认为删除。
# 保留断点可用于调试,但有可能泄漏数据源的元数据。
keep-after-success = false

2、命令行控制参数--checkpoint-error-destroy

# 让失败的表重新开始导入
示例:

## 该命令会让失败的表从头开始整个导入过程。选项中的架构和表名必须以反引号 (`) 包裹,而且区分大小写
--checkpoint-error-destroy='`schema`.`table`'

## 传入 "all" 会对所有表进行上述操作。这是最方便、安全但保守的断点错误解决方法(推荐使用)
tidb-lightning-ctl --checkpoint-error-destroy=all

3、命令行控制参数--checkpoint-error-ignore

# 忽略出错状态,忽略错误继续导入
示例:
--checkpoint-error-ignore='`schema`.`table`' 
--checkpoint-error-ignore=all

## 如果导入的地方出错了,也会忽略错误接着倒入。

4、命令行控制参数--checkpoint-remove

# 只要断点传输出现错误,所有数据重新导入
--checkpoint-remove='`schema`.`table`'
--checkpoint-remove=all

库表过滤(4.0以上版本)

1、命令行

# 在命令行中使用多个 -f 或 --filter 参数
--filter=test.t*,test1.t*

2、配置文件配置

vim  tidb-lightning.toml 
[mydumper]
filter = ['foo*.*', 'bar*.*']

3、支持的通配符

db[0-9].tbl[0-9a-f][0-9a-f]
data.*
*.backup_*

lightning web界面配置

1、命令行配置方法

./tidb-lightning --server-mode --status-addr :8289

2、配置文件配置方法

vim  tidb-lightning.toml
[lightning]
server-mode = true
status-addr = ':8289'

3、访问方法

打开网页访问 "http://IP:8289" 即可

# 数据量小的情况下是无法打开web界面的,导入完成后会自动关闭web程序
相关文章
|
SQL 关系型数据库 MySQL
TiDB亿级数据亚秒响应查询将MySql数据全量迁移到TiDB
TiDB亿级数据亚秒响应查询将MySql数据全量迁移到TiDB
629 0
|
SQL 关系型数据库 MySQL
TiDB安装简介
TiDB安装简介
2794 0
|
缓存
npm install 一直卡着不动如何解决
npm install 一直卡着不动如何解决
7417 0
|
Linux 网络安全 Python
如何在服务器上运行python文件
如何在服务器上运行python文件
|
关系型数据库 MySQL 调度
【TiDB原理与实战详解】4、DM 迁移和TiCDC数据同步~学不会? 不存在的!
TiDB Data Migration (DM) 和 TiCDC 是两款用于数据库迁移和同步的强大工具。DM 支持将兼容 MySQL 协议的数据库(如 MySQL、MariaDB)的数据异步迁移到 TiDB 中,具备全量和增量数据传输能力,并能合并分库分表的数据。TiCDC 则专注于 TiDB 的增量同步,利用 TiKV 日志实现高可用性和水平扩展,支持多种下游系统和输出格式。两者均可通过 TiUP 工具进行部署与管理,简化了集群的安装、配置及任务管理过程。
|
9月前
|
SQL JSON 数据可视化
基于 DIFY 的自动化数据分析实战
本文介绍如何使用DIFY搭建数据分析自动化流程,实现从输入需求到查询数据库、LLM分析再到可视化输出的全流程。基于经典的employees数据集和DIFY云端环境,通过LLM-SQL解析、SQL执行、LLM数据分析及ECharts可视化等模块,高效完成数据分析任务。此方案适用于人力资源分析、薪酬管理等数据密集型业务,显著提升效率并降低成本。
13182 16
|
存储 关系型数据库 MySQL
【TiDB原理与实战详解】5、BR 物理备份恢复与Binlog 数据同步~学不会? 不存在的!
BR(Backup & Restore)是 TiDB 分布式备份恢复的命令行工具,适用于大数据量场景,支持常规备份恢复及大规模数据迁移。BR 通过向各 TiKV 节点下发命令执行备份或恢复操作,生成 SST 文件存储数据信息与 `backupmeta` 文件存储元信息。推荐部署配置包括在 PD 节点部署 BR 工具,使用万兆网卡等。本文介绍 BR 的工作原理、部署配置、使用限制及多种备份恢复方式,如全量备份、单库/单表备份、过滤备份及增量备份等。
|
存储 SQL 关系型数据库
技术好文:TiDB架构及设计实现
技术好文:TiDB架构及设计实现
1039 0
|
存储 SQL Prometheus
【TiDB原理与实战详解】1、原理与基础优化~学不会? 不存在的!
TiDB 是一款开源的分布式关系型数据库,具备水平扩展、高可用性和强一致性等特点,适用于高并发、低延迟的大规模数据处理场景。其架构设计灵感源自 Google 的 Spanner 和 F1,并兼容 MySQL。TiDB 集群由 TiDB Server(无状态 SQL 层)、PD(元数据管理模块)和 TiKV Server(分布式存储层)组成,还包含 TiFlash(列存储引擎)以加速分析型查询。TiDB 支持分布式事务和多种事务模式,适用于 OLTP 和 HTAP 场景,如电商平台和金融系统。此外,TiDB 的部署要求包括高性能硬件配置和特定网络设置,以确保系统的稳定性和高效运行。
|
运维 监控 安全
【TiDB原理与实战详解】2、部署与节点的扩/缩容~学不会? 不存在的!
TiUP 是 TiDB 4.0 引入的集群运维工具,TiUP cluster 用于部署、管理 TiDB 集群,支持 TiDB、TiFlash、TiDB Binlog 等组件。本文介绍使用 TiUP 部署生产环境的具体步骤,包括节点规划、工具安装、配置文件修改及集群部署等。同时,提供了常用命令和安全优化方法,并详细说明了如何进行集群的扩缩容操作,以及时区设置等维护工作。