准备升级的小伙伴们有福啦！表妹给你准备了一份超级齐全的升级指南，大家可以借鉴一下：
实战-记录一次大版本升级 （4.0.13→5.4.0）
一. 背景
- 目前本公司TiDB集群已经运行5个业务系统数据库。这5个业务都是公司相对重要的业务系统，具有高并发写入、高并发查询或大批量数据查询的特征。
- TiDB产品迭代速度较快，TiDB v5.4.0 GA版本虽然比TiDB v4.0.13晚一年左右，但是却有较大的功能与性能改进（已测试）能够提升写入性能，查询性能，尤其是多表联合查询（mpp）提升较大。
二. 升级目的
- 提升TiDB集群写入性能和查询性能，5.4.0比4.0.13提升10-15%左右。
- TiFlash组件增加MPP（查询下推）功能，较大幅度提升TiDB集群多表连接查询性能。
- 提升更友好的维护与管理方式。
- 新集群服务器替换旧集群服务器，TiDB集群整体最大承载能力提升2倍左右。
目录：
更多详情：专栏 - 实战-记录一次大版本升级 | TiDB 社区
《TiDB跨版本升级》 --流程概述 （3.0.10→5.3.0）
升级背景
-
原集群版本过低，运维难度大，决定进行版本升级
-
经过测试发现，v5.3.0版本相对于v3.0.10版本性能有很大提升
-
决定将TiDB v3.0.10升级到TiDB v5.3.0
升级方式
本方案采用Dumpling+Lightning+TiDB Binlog的方式进行
【升级方式划分】
大体分为停机升级 与不停机升级
根据字面意思理解，我们可以根据业务的要求来进行选择，如果业务允许进行停机升级，那相对来说我们选择停机升级
会更加的安全，快速，如果业务不允许停机的话我们主要选择就是不停机升级不停机升级 根据官方文档来看，需要通过特定方式来进行滚动升级
滚动升级对于我们来说或许是一个很好的选择，但问题就是：
1、业务需求回滚，我们的回滚方案通常需要针对于全备+增量的方式来进行回滚，回滚进度较慢
2、因版本差距过大的话，连续进行滚动升级，不可控因素增多
3、老版本通常采用Ansible安装，又想让新版本适用tiup进行管理，操作起来较为复杂
#因为种种因素原因，最终决定采用Dumpling+Lightning+TiDB Binlog的方式，可以有效的规避一系列繁琐问题。
-
获取相关信息
-
创建TiDB v5.3.0的目标集群
-
Dumpling对原集群进行数据导出
-
Lightning对目标集群进行数据导入
-
启动Drainer进行增量同步
-
sync-diff-inspector进行数据校验
-
搭建回滚链路
-
切换业务
更多详情：专栏 - 《TiDB跨版本升级》 --流程概述 | TiDB 社区
TiDB升级与案例分享（TiDB v4.0.1 → v5.4.1）
为什么要升级？
- 低版本 TiDB 周边组件支持不完善，如低版本的 cdc 的支持并不完善，有内存泄露问题等；
- 实际工作中触发过 TiDB 的 panic bug；
- 在降本增效的大背景下，提升 TiDB 的性能或吞吐量；
- 为社区贡献实际业务场景；
如何升级？
TiDB 的升级分为 停机升级 和 不停机升级， 不停机升级又 分平滑升级 和 强制升级 (–force)，下面简单说明下过程，不对细节过多展开，只介绍核心
目录：
更多详情：专栏 - TiDB升级与案例分享（TiDB v4.0.1 → v5.4.1） | TiDB 社区
高并发请求下 TiDB 集群的业务无损升级
目 录
一、前言
二、常见的联机交易系统升级方式
三、升级 TiDB 集群的常见问题
- SQL 请求失败
- 升级前后版本不兼容导致升级失败
- 未制定升级失败的回退计划
四、升级准备及非核心组件的升级
- 升级前的准备工作
- 周边组件的升级
五、TiDB 集群核心组件的在线升级
- 核心组件升级顺序
- 使用 tiup cluster patch 操作各组件分别升级
- 升级 PD
- 升级 TiKV
- 升级 Pump
- 升级 TiDB
更多详情：专栏 - 高并发请求下 TiDB 集群的业务无损升级 | TiDB 社区
TiDB跨版本升级–新人首次尝试（3.0.8→5.4.0）
升级背景
-
原集群版本过低，运维难度大，决定进行版本升级
-
经过测试发现，v5.4.0版本相对于v3.0.10版本性能有很大提升
-
决定将TiDB v3.0.10升级到TiDB v5.4.0
升级方式
本次升级采用Dumpling+Lighting+TiDB binlog进行
【升级方式划分】
大体分为停机升级 与不停机升级
根据字面意思理解，我们可以根据业务的要求来进行选择，如果业务允许进行停机升级，那相对来说我们选择停机升级
会更加的安全，快速，如果业务不允许停机的话我们主要选择就是不停机升级不停机升级 根据官方文档来看，需要通过特定方式来进行滚动升级
滚动升级对于我们来说或许是一个很好的选择，但问题就是：
1、业务需求回滚，我们的回滚方案通常需要针对于全备+增量的方式来进行回滚，回滚进度较慢
2、因版本差距过大的话，连续进行滚动升级，不可控因素增多
3、老版本通常采用Ansible安装，又想让新版本适用tiup进行管理，操作起来较为复杂
#因为种种因素原因，最终决定采用Dumpling+Lightning+TiDB Binlog的方式，可以有效的规避一系列繁琐问题。
-
获取相关信息
-
创建TiDB v5.3.0的目标集群
-
Dumpling对原集群进行数据导出
-
Lightning对目标集群进行数据导入
-
启动Drainer进行增量同步
-
sync-diff-inspector进行数据校验
-
搭建回滚链路
-
切换业务
更多详情：专栏 - TiDB跨版本升级--新人首次尝试🧐 | TiDB 社区
有关 TiDB 升级的二三事——教你如何快乐升级 （4.0.9→4.0.14）
更多详情：专栏 - 有关 TiDB 升级的二三事——教你如何快乐升级 | TiDB 社区
TiDB升级5.0.2有惊喜 （5.0.1 → 5.0.2）
更多详情：专栏 - TiDB升级5.0.2有惊喜 | TiDB 社区
TiDB 4.0 升级 5.1 二三事——避坑指南 （4.0→5.1）
更多详情：专栏 - TiDB 4.0 升级 5.1 二三事——避坑指南 | TiDB 社区
TiDB 2.1升级到4.0操作文档
更多详情：专栏 - tidb 2.1升级到4.0操作文档 | TiDB 社区
TiDB4PG 中 TiDB 版本升级至 v5.3.0
更多详情：专栏 - TiDB4PG 中 TiDB 版本升级至 v5.3.0 | TiDB 社区
TTIDB 监控升级解决panic的漫漫探索之路
更多详情：专栏 - TIDB监控升级解决panic的漫漫探索之路 | TiDB 社区
