一. 背景

目前本公司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 v4.0.13版本是本公司TiDB集群使用的第一个版本，经过了大量的测试，包括白盒测试和业务测试，并且使用至今基本无重大问题出现，整体较为稳定。而TiDB v5.4.0版本虽然是官方发布的GA版本，但是版本较新，稳定性需要时间来检验。

TiDB v5.4.0是大版本5.4的第一个版本，可能会存在bug，后期需要通过小版本升级修复bug list，比如升级到5.4.1。

为保证升级期间对业务影响最小，采用集群替换方式，保证一个集群升级出现问题，另一个能随时接管业务。

四. 官方说明

1、版本新特性

TiDB 5.0 Release Notes

发版日期：2021 年 04 月 07 日

5.0 版本中，我们专注于帮助企业基于 TiDB 数据库快速构建应用程序，使企业在构建过程中无需担心数据库的性能、性能抖动、安全、高可用、容灾、SQL 语句的性能问题排查等问题。

在 5.0 版本中，你可以获得以下关键特性：

TiDB 通过 TiFlash 节点引入了 MPP 架构。这使得大型表连接类查询可以由不同 TiFlash 节点共同分担完成。当 MPP 模式开启后，TiDB 将会根据代价决定是否应该交由 MPP 框架进行计算。MPP 模式下，表连接将通过对 JOIN Key 进行数据计算时重分布（Exchange 操作）的方式把计算压力分摊到各个 TiFlash 执行节点，从而达到加速计算的目的。经测试，TiDB 5.0 在同等资源下，MPP 引擎的总体性能是 Greenplum 6.15.0 与 Apache Spark 3.1.1 两到三倍之间，部分查询可达 8 倍性能差异。

引入聚簇索引功能，提升数据库的性能。例如，TPC-C tpmC 的性能提升了 39%。

开启异步提交事务功能，降低写入数据的延迟。例如：Sysbench 设置 64 线程测试 Update index 时, 平均延迟由 12.04 ms 降低到 7.01ms ，降低了 41.7%。

通过提升优化器的稳定性及限制系统任务对 I/O、网络、CPU、内存等资源的占用，降低系统的抖动。例如：测试 8 小时，TPC-C 测试中 tpmC 抖动标准差的值小于等于 2%。

通过完善调度功能及保证执行计划在最大程度上保持不变，提升系统的稳定性。

引入 Raft Joint Consensus 算法，确保 Region 成员变更时系统的可用性。

优化 EXPLAIN 功能、引入不可见索引等功能帮助提升 DBA 调试及 SQL 语句执行的效率。

通过从 TiDB 备份文件到 Amazon S3、Google Cloud GCS，或者从 Amazon S3、Google Cloud GCS 恢复文件到 TiDB，确保企业数据的可靠性。

提升从 Amazon S3 或者 TiDB/MySQL 导入导出数据的性能，帮忙企业在云上快速构建应用。例如：导入 1TiB TPC-C 数据性能提升了 40%，由 254 GiB/h 提升到 366 GiB/h。

TiDB 5.1 Release Notes

发版日期：2021 年 6 月 24 日

在 5.1 版本中，你可以获得以下关键特性：

支持 MySQL 8 中的公共表表达式 (Common Table Expression)，提高了 SQL 语句的可读性与执行效率。

支持对数据表列类型的在线变更，提高了业务开发的灵活性。

引入一种新的统计信息类型，默认作为实验特性启用，提升查询稳定性。

支持 MySQL 8 中的动态权限 (Dynamic Privileges) 配置，实现对某些操作更细粒度的控制。

支持通过 Stale Read 功能直接读取本地副本数据，降低读取延迟，提升查询性能（实验特性）。

新增锁视图 (Lock View) 功能方便 DBA 观察事务加锁情况以及排查死锁问题（实验特性）。

新增 TiKV 后台任务写入限制（TiKV Write Rate Limiter)，保证读写请求的延迟稳定性。

TiDB 5.2 Release Notes

发版日期：2021 年 8 月 27 日

在 5.2 版本中，你可以获得以下关键特性：

支持基于部分函数创建表达式索引 (Expression index)，极大提升查询的性能。

提升优化器的估算准确度 (Cardinality Estimation)，有助于选中最优的执行计划。

锁视图 (Lock View) 成为 GA 特性，提供更直观方便的方式观察事务加锁情况以及排查死锁问题。

新增 TiFlash I/O 限流功能，提升 TiFlash 读写稳定性。

为 TiKV 引入新的流控机制代替之前的 RocksDB write stall 流控机制，提升 TiKV 流控稳定性。

简化 Data Migration (DM) 工具运维，降低运维管理的成本。

TiCDC 支持 HTTP 协议 OpenAPI 对 TiCDC 任务进行管理，在 Kubernetes 以及 On-Premises 环境下提供更友好的运维方式。(实验特性)yix

TiDB 5.3 Release Notes

发版日期：2021 年 11 月 30 日在 v5.3.0 版本中，你可以获得以下关键特性：

引入临时表，简化业务逻辑并提升性能

支持设置表和分区的表属性

支持为 TiDB Dashboard 创建最小权限用户，提高系统安全性

优化 TiDB 时间戳处理流程，提升系统的整体性能

提高 DM 同步性能，实现以更低的延迟将数据从 MySQL 同步数据到 TiDB

支持 TiDB Lightning 分布式并行导入，提升全量数据迁移效率

支持“一键”保存和恢复现场问题的相关信息，提升查询计划问题诊断的效率

支持持续性能分析 (Continuous Profiling) 实验特性，提高数据库性能的可观测性

持续优化存储和计算引擎，提升系统性能和稳定性

降低 TiKV 写入延迟，从 Raftstore 线程池中分离出 IO 线程池（默认不开启）

TiDB 5.4 Release Notes

发版日期：2022 年 2 月 15 日

在 v5.4.0 版本中，你可以获得以下关键特性：

支持 GBK 字符集

支持索引合并 (Index Merge) 数据访问方法，能够合并多个列上索引的条件过滤结果

支持通过 session 变量实现有界限过期数据读取

支持统计信息采集配置持久化

支持使用 Raft Engine 作为 TiKV 的日志存储引擎（实验特性）

优化备份对集群的影响

支持 Azure Blob Storage 作为备份目标存储

持续提升 TiFlash 列式存储引擎和 MPP 计算引擎的稳定性和性能

为 TiDB Lightning 增加已存在数据表是否允许导入的开关

优化持续性能分析（实验特性）

TiSpark 支持用户认证与鉴权

2、版本兼容性

兼容项

5.0.0

5.1.0

5.2.0

5.3.0

5.4.0

系统变量 配置文件 其他

此处内容过多，省略

3. github issue

bel%3Aaffects-5.4

五. 升级流程

预发环境k8s连接预发环境TiDB新集群集群进行业务测试，版本v5.4.0。

生产环境部署新集群TiDB v5.4.0。

现有集群TiDB v4.0.13部署binlog drainer同步到TiDB新集群v5.4.0。

业务低峰期，根据dns域名切换+haproxy切换的方式切换到新集群。

将旧集群做成新集群的从集群，用于随时回退。

稳定运行一个月，下线旧集群。

六. 服务器规划

1、新版本集群

2、旧版本集群

七. 测试报告

1、sysbench混合性能测试，读写比3:1

列说明：

第1列：并发数

第2列：4.0.13版本，原集群服务器，tps

第3列：4.0.13版本，新集群服务器，tps

第4列：5.4.0版本，新集群服务器，tps

2、TiFlash单个sql查询测试

测试结果：

3、TiKV单个sql查询测试

测试结果：

八. 升级操作步骤

原集群部署tidb binlog drainer同步到新版本集群（先进行全量数据导出导入）。

以下操作均在业务低峰期进行，切换原则是对业务影响最小为最佳。

根据切换的业务域名（有多个业务，使用不同的域名，每次只切换一个业务），通过dns域名管理系统，将域名指向到原集群的备用haproxy（原集群包括两个haproxy，一个主，一个备）的vip上。

业务相关的k8s服务滚动重启（对业务无影响），保证切换业务的数据库连接，连到备用haproxy上。

通过dns域名管理系统，将切换业务的域名指向新版本5.4.0集群的主haproxy vip。

设置新版本集群只读，此操作为了避免集群双写，新集群只读不超过10秒，避免对业务影响太大。

原集群备用haproxy重启，释放切换业务的数据库连接。

设置新版本集群可写。

查看新集群和原集群数据库连接迁移情况，全部迁移完成后，切换成功。

包含自增id属性的表，在新集群执行语句：alter table table_name auto_id_cache 30000; ，此操作刷新自增id值，避免新集群出现主键重复（踩过的坑）。

回收原集群的业务账号权限（避免非常规操作继续往原集群写数据）。

原集群binlog drainer停止。

新集群部署binlog drainer，同步到原集群，保证随时可回退到原集群，先找到切换时间点的tso，根据此tso部署drainer。

业务相关的操作，比如业务回归测试等，至此，切换完成。

九. 回退

将域名切回至原集群即可

十. 经验总结

最早打算使用ip漂移的方式，但是考虑到影响业务面积太大，所以改为按业务域名切换，一次切换只影响一个业务，出现bug等问题不至于全业务瘫痪

切换前需要确认所有业务使用的是域名，而不是直连IP，如果直连IP，需要改为连接域名

切换到新版本集群后，出现了主键重复的问题，原因应该是新集群的表自增id初始值小于原集群的最大值，这个问题出现过多次，之前使用dm，从mysql切换到tidb集群也出现过，解决方法是alter table table_name auto_id_cache 30000；

切换之后触发tiflash的bug，具体见：https://asktug.com/t/topic/694454

切换之后频繁出现tidb内存使用过高的问题，修改参数prepared-plan-cache.capacity，从50000改为10000，重启tidb server后恢复正常

切换后tiflash使用效果大幅提升，写入也相对快了一些，整体效果较好，目前已进入稳定期