跳到主要内容

实战-记录一次大版本升级

作者:magongyong

一. 背景

  • 目前本公司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.05.1.05.2.05.3.05.4.0
系统变量
配置文件
其他

此处内容过多,省略

3、github issue

https://github.com/pingcap/tidb/issues?page=2&q=is%3Aopen+is%3Aissue+label%3Aaffects-5.4

五. 升级流程

  1. 预发环境k8s连接预发环境TiDB新集群集群进行业务测试,版本v5.4.0。
  2. 生产环境部署新集群TiDB v5.4.0。
  3. 现有集群TiDB v4.0.13部署binlog drainer同步到TiDB新集群v5.4.0。
  4. 业务低峰期,根据dns域名切换+haproxy切换的方式切换到新集群。
  5. 将旧集群做成新集群的从集群,用于随时回退。
  6. 稳定运行一个月,下线旧集群。

六. 服务器规划

1、新版本集群

图片.png

2、旧版本集群

图片.png

七. 测试报告

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

图片.png列说明:

第1列:并发数

第2列:4.0.13版本,原集群服务器,tps

第3列:4.0.13版本,新集群服务器,tps

第4列:5.4.0版本,新集群服务器,tps

2、TiFlash单个sql查询测试

测试结果:

图片.png

3、TiKV单个sql查询测试

测试结果:

图片.png

八. 升级操作步骤

  1. 原集群部署tidb binlog drainer同步到新版本集群(先进行全量数据导出导入)。
  2. 以下操作均在业务低峰期进行,切换原则是对业务影响最小为最佳。
  3. 根据切换的业务域名(有多个业务,使用不同的域名,每次只切换一个业务),通过dns域名管理系统,将域名指向到原集群的备用haproxy(原集群包括两个haproxy,一个主,一个备)的vip上。
  4. 业务相关的k8s服务滚动重启(对业务无影响),保证切换业务的数据库连接,连到备用haproxy上。
  5. 通过dns域名管理系统,将切换业务的域名指向新版本5.4.0集群的主haproxy vip。
  6. 设置新版本集群只读,此操作为了避免集群双写,新集群只读不超过10秒,避免对业务影响太大。
  7. 原集群备用haproxy重启,释放切换业务的数据库连接。
  8. 设置新版本集群可写。
  9. 查看新集群和原集群数据库连接迁移情况,全部迁移完成后,切换成功。
  10. 包含自增id属性的表,在新集群执行语句:alter table table_name auto_id_cache 30000; ,此操作刷新自增id值,避免新集群出现主键重复(踩过的坑)。
  11. 回收原集群的业务账号权限(避免非常规操作继续往原集群写数据)。
  12. 原集群binlog drainer停止。
  13. 新集群部署binlog drainer,同步到原集群,保证随时可回退到原集群,先找到切换时间点的tso,根据此tso部署drainer。
  14. 业务相关的操作,比如业务回归测试等,至此,切换完成。

九. 回退

将域名切回至原集群即可

十. 经验总结

  1. 最早打算使用ip漂移的方式,但是考虑到影响业务面积太大,所以改为按业务域名切换,一次切换只影响一个业务,出现bug等问题不至于全业务瘫痪
  2. 切换前需要确认所有业务使用的是域名,而不是直连IP,如果直连IP,需要改为连接域名
  3. 切换到新版本集群后,出现了主键重复的问题,原因应该是新集群的表自增id初始值小于原集群的最大值,这个问题出现过多次,之前使用dm,从mysql切换到tidb集群也出现过,解决方法是alter table table_name auto_id_cache 30000;
  4. 切换之后触发tiflash的bug,具体见:https://asktug.com/t/topic/694454
  5. 切换之后频繁出现tidb内存使用过高的问题,修改参数prepared-plan-cache.capacity,从50000改为10000,重启tidb server后恢复正常
  6. 切换后tiflash使用效果大幅提升,写入也相对快了一些,整体效果较好,目前已进入稳定期