攻克多版本运维难题：爱奇艺百套 TiDB 集群升级至 v7.1.5 实战宝典来袭！

导读

爱奇艺作为业内知名的在线视频平台，凭借其丰富多样的内容和优质的用户体验，业务增长迅猛，数据量也随之剧增。为了满足业务需求，爱奇艺自 2017 年开始使用 TiDB，应用涵盖 30 多个业务线，服务器数量超过 500 台，集群数量超过 100 个，同时运行的 TiDB 版本数量达 20+。本文将深入探讨爱奇艺如何通过升级，成功将百套 TiDB 集群从多个旧版本升级至 v7.1.5，攻克多版本运维挑战，获得更稳更快的 TiDB 使用体验。

TiDB 社区活动（上海站）回顾

TiDB 社区活动（上海站）回顾 & ppt 下载： 【TiDB 上海地区交流回顾】TiDB 在小红书、爱奇艺、咪咕、华安基金、数禾科技的核心场景/简化技术栈/降本增效实践

爱奇艺选择 TiDB 的理由

应对业务增长与数据挑战

随着互联网用户对内容需求的增长，爱奇艺的业务规模迅速扩大，数据量和会员数不断攀升。传统的分库分表方式在数据校验和流量切换方面逐渐显得力不从心，严重影响了业务的高效运行。TiDB 以其卓越的分布式架构和强大的数据处理能力，为爱奇艺提供了一个超大号的 MySQL 解决方案，有效解决了分库分表带来的诸多痛点，确保了数据的一致性和业务的稳定性。

应对业务增长与数据挑战

利用 TiFlash 列存特性与节点扩展性

TiDB 的 TiFlash 列存特性为爱奇艺带来了显著的性能提升。通过利用 TiFlash，爱奇艺能够高效地进行数据分析和查询，加速了业务决策过程。此外，TiDB 节点的易扩展性使得爱奇艺能够灵活地应对不断增长的数据量和业务需求。不同的 TiDB 节点可以分别处理 TP（事务处理）和 AP（分析处理）任务，实现了读取一份数据即可满足多种业务需求，避免了繁琐的 ETL 数据清洗工作，进一步提高了业务的响应速度和决策效率。

爱奇艺 TiDB 使用情况

集群规模、数据量及应用场景

自 2017 年开始使用 TiDB 以来，爱奇艺的 TiDB 集群规模不断扩大。截至目前，爱奇艺拥有超过 500 台服务器，集群数量超过 100 个。单集群数据量从 300G 到 40T 不等，涵盖了会员数据归档、风控、BI、素材、营销数据、设备指纹等 30 多个应用业务线。这些集群不仅支撑了爱奇艺的核心业务，还为数据的高效存储和快速访问提供了坚实保障。

爱奇艺 TiDB 使用情况

版本管理与运维挑战

随着业务的不断发展，爱奇艺的 TiDB 集群中运行着多个不同版本，从 v3.0.19 到 v6.0.x 共有 20 多个版本在线运行。多版本并行不仅增加了运维的复杂性，还给自动化运维带来了诸多挑战。针对版本管理和运维面临挑战，爱奇艺数据库团队对 TiDB v7 版本进行全面评估和方案设计，决定所有集群升级到 TiDB 社区推荐版本。

爱奇艺 TiDB 升级实践

升级的理由

1. 简化运维管理 ：不同版本之间的参数差异使得运维团队需要投入更多的时间和精力确保各个版本的稳定运行。升级至统一的版本不仅可以减少运维的复杂性，还能提高自动化运维的效率。
2. 修复现有问题 ：应用遇到的 bug 在新版本中都得到修复，TiDB 新版本稳定性有显著提升。
3. 应用新版本特性 ：TiDB 新版本的诸多特性，如 TiCDC、数据自动清理 TTL、SPM 执行计划管理、快速加索引、BR 日志备份等，通过升级至 TiDB V7 版本，能充分利用这些新特性，进一步优化数据管理以及业务开发效率。

升级方案的制定

升级方案选择

爱奇艺在升级过程中主要考虑了两种方案：原地升级和迁移升级。原地升级的优势在于操作简单，无需额外的硬件资源，但存在不支持回退、升级过程中禁止用户发起 DDL 操作等风险。迁移升级则具有业务影响时间短、不受版本跨度限制、可回退等优点，但需要额外的硬件资源，成本较高。根据集群的实际情况和业务需求，爱奇艺灵活运用这两种方案，确保了升级过程的顺利进行。

升级方案选择

升级路线规划

爱奇艺采取了分版本逐步升级的策略，从 v3 开始，依次升级到 v4、v5、v6，最后升级到 v7。这一策略参考了滴滴跨版本的升级经验，避免了一次性跨越多个版本带来的风险。同时，爱奇艺优先在测试环境中进行升级，并让业务团队进行充分验证，确保升级方案的可行性和稳定性。此外，团队还优先升级了 v6 和 v5 版本的集群，因为这两个版本尚未到达生命周期末期，可以在社区中寻求厂商支持，及时解决升级过程中遇到的问题。对于流量小、容量小的非核心业务集群，爱奇艺也优先进行了升级，通过观察升级过程中的问题，进一步优化了升级 SOP。

升级历程与问题解决

在升级过程中，爱奇艺遇到了一些问题，并找到了相应的解决思路。

1. 部分业务报错 ：升级后，部分业务出现 org.springframework.jdbc.UncategorizedSQLException 错误，提示 client has multi - statement capability disabled。原因是 TiDB 高版本默认不允许在同一 COM_QUERY 调用中执行多个查询，以减少 SQL 注入攻击的影响。解决方案是将 tidb_multi_statement_mode 变量值设为 ON，以适配专为早期 TiDB 版本设计的业务。
2. drainer 无法启动 ：在测试集群 v4.0.16 跨版本升级 v7.1.4 时，drainer 升级时提示端口无法启动。尝试回退至 v5.4.3 继续升级，却因 V7 与 V5 版本 TiKV 目录发生改变，导致 TiKV 异常退出。正确的解决方法是记录 drainer 日志中的 savepoint 位点，缩容 drainer 组件，升级完成后，再用指定位点的方式扩容 drainer 组件。此外，可能与服务器上一个异常的 NFS 服务有关。
3. 业务逻辑有 DDL 导致 drainer 启动失败 ：升级过程中，业务自行 DDL，造成表的 table_id 不一致，drainer 无法启动。业务对中间表进行了 truncate & load data 操作，导致 table id 发生变化，drainer 在启动时有此检查项，从而启动失败。最终通过更换 cdc 同步，重做同步链路解决问题。为避免类似问题，每次升级前都会执行 admin show ddl jobs 命令查看近期是否有 ddl 任务，提前告知业务升级时不能 ddl，如有定时任务 ddl，在业务低峰期暂停相关定时任务，回收账户的 ddl 权限，升级完成后，再重新赋权。
4. sync-log = false 与海量 region 调度引起升级后报 tikv : 9001 pd server 超时：升级后出现 tikv : 9001 pd server 超时的错误，导致查询语句失败率升高至 5% - 10%，更新语句失败率升高至 50% - 70%，插入语句正常。原因是集群早期对一些 TiKV 设置了 sync-log = false，在强制重启的情况下可能需要短时间内补副本以维护数据一致性，引发 pd 调度升高；同时，集群数据量巨大，默认的 trace-region-flow = true 参数在需要大量补副本的场景下，影响了 pd 与 TiKV 之间的心跳导致 pd 大量超时。解决方案是修改 trace-region-flow 参数为 false，并重启 pd server。

升级整体感受

在 TiDB 升级过程中，我们看到了基础服务正常（如 NFS、NTP 服务）、业务充分验证的情况下，滚动升级比较简单平滑，90+ 集群升级下来，仅 2 套集群升级遇到问题。升级后，有效收敛了业务高峰期 P99 duration 高和负载高的告警数量。运维也变得更加简易，白屏化的绑定执行计划、更短的添加索引时间，使得在慢 SQ L 导致集群性能下降的情况下，能够更快地恢复集群性能，减少故障时间。

升级历程

爱奇艺 TiDB 升级收益

升级后，TiDB 集群在性能和稳定性等方面取得了显著提升。

1. 性能提升与稳定性增强 ：升级后，小的毛刺 SQL 消失，稳定性提高。例如，一个 BI 的 AP 类集群，升级后 SQL 耗时从 8s 降至 2s，聚合计算 SQL 性能提升，稳定性增加。
2. 数据管理优化 ：利用 TTL 功能清理冗余数据，有效管理数据生命周期。同时，dashboard 快速绑定执行计划，简化了操作流程，提高了运维效率。
3. 备份与恢复能力提升 ：br 支持日志备份，可灵活选择恢复时间点，实现 Point-in-time recovery，为数据安全提供了更有力的保障。
4. 同步任务稳定性增强 ：TiCDC 将大事务拆分为小消息体，Kafka 不会因消息体过大而导致 OOM，相关同步任务更加稳定。
5. 运维效率提升 ：大表添加索引时间由之前的 13h 降至 20min，大大加快了运维速度，减少了故障恢复时间。

来自社区的助力与未来展望

在 TiDB 运维和升级的过程中，TiDB 官方社区给予了大力的支持和帮助，为本次升级工作提供了有力的技术保障。

爱奇艺的 TiDB 升级实践证明了 TiDB 在大规模数据处理和业务支撑方面的强大能力，也非常期待 TiDB 在数据清理速度、SQL 性能优化等方面进一步提升，得以满足不断增长的业务需求。 未来，爱奇艺将继续与 TiDB 携手，共同探索更多优化和创新的可能性，为用户提供更加优质、稳定的服务。