跳到主要内容

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

作者：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使用效果大幅提升，写入也相对快了一些，整体效果较好，目前已进入稳定期