实战 - 记录一次大版本升级
作者: magongyong 原文来源:https://tidb.net/blog/eb33aa71
一. 背景
- 目前本公司 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、版本兼容性
此处内容过多,省略
3. github issue
https://github.com/pingcap/tidb/issues?page=2&q=is%3Aopen+is%3Aissue+label%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 使用效果大幅提升,写入也相对快了一些,整体效果较好,目前已进入稳定期 
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/59e54286a10afa8c3d68c7f24】。文章转载请联系作者。










 
    
评论