杭州百腾教育科技 TiDB 6.5 to 7.5 升级记录
作者： reAsOn2010 原文来源：https://tidb.net/blog/612103f3
背景
使用 TiDB 作为我们的全量数据库已经有六七年了，当时还是 2.0 版本。早期 TiDB 的迭代和新特性的发布对于实际使用的影响还是很大的，所以从那个时候开始就有每年的例行升级运维。
而每年暑假都是我们业务的低谷时间，自然选择在 7 月底 8 月初左右进行这次的升级。
事实上 TiDB 6.5 在使用上已经相当稳定了，当然我们仍然选择了更新的 LTS 作为这次的升级目标。
官方这次的升级互助活动提供的升级方案基本上都是使用 TiUP 进行的，而我们的 TiDB 集群已经全部纳入 K8S 管理，所以我们这次的升级是通过 TiDB Operator 进行。 升级时间 2024.07.29
升级流程
准备工作
感谢表妹在群里分享的 TiDB 参数变更，一路升级上来除了有一次重建了新集群，其他时候都没有特别去调整参数配置。升级前已经是 6.5 了，所以直接应用一下推荐值，排查发现有 2 个参数需要变更。
这边整理版本升级到 v6.x 以上的一些系统变量和配置项默认值改变一些参数，一般情况在升级后可以直接设置，建议排查下刚升级的集群
set global tidb_server_memory_limit=“80%”; – 该参数请根据实际情况调整
set global tidb_enable_rate_limit_action=false;
set global tidb_enable_paging=ON;
set global tidb_enable_pseudo_for_outdated_stats=OFF;
set global tidb_enable_outer_join_reorder=ON;
set global tidb_stats_load_sync_wait=100;
set global tidb_stats_load_pseudo_timeout=ON;
set global tidb_enable_index_merge=ON;
set global tidb_prepared_plan_cache_size = 50;
TiDB Server 实例内存阈值 <= 64 GiB 时，tidb_prepared_plan_cache_size = 50
TiDB Server 实例内存阈值 > 64 GiB 时，tidb_prepared_plan_cache_size = 100
tidb_ddl_enable_fast_reorg 从 v6.3.0 版本开始引入 6.5 默认值为 on，如需正确使用但需要正确配置 temp-dir, 如使用该功能可以关闭
set global tidb_ddl_enable_fast_reorg = off;
然后查一下对应的版本，集群将要升级到 7.5，查询官方文档可知 TiDB Operator 的版本推荐为 1.5。所以我们将要升级到 v1.5.3
正式开始
升级 TiDB Operator
先更新 CRD
我们使用 kustomize 来管理所有 K8S 上的资源，所以升级比较简单，更新掉版本号就好。
等待新实例启动，观察日志出现类似如下的信息，代表已经完成。理论上升级 TiDB Operator 不会引起 TiDB 本身的更新，兼容性没问题的话，会直接进入 ready 的状态。
升级 TiDB
更新 CRD 里的 version 参数即可。 同样我们的 CRD 也是用 kustomize 管理的，所以更新版本号
应用后，TiDB Operator 就会马上开始滚动升级，PD → TiKV → TiDB → TiCDC。我们线上是一个最小高可用规模的集群，大概花费半个小时左右的事件就能滚动升级完毕，消耗时间较长的是 TiKV 和 TiCDC，过程中需要迁移 leader 以保证尽可能的平滑，需要等待一些时间。
建议通过观察 TiDB Operator 日志来确定是否升级完毕
升级 DM
我们通过一组 DM 同步 MySQL 数据到 TiDB 当中，升级完 TiDB 后配套升级 DM。
同样是更新 CRD 里的 version 参数
DM 的升级过程相当快，基本上都可以看作是无状态的服务，重启了就好了。
建议通过观察 TiDB Operator 日志来确定是否升级完毕
升级 TiDB Monitor
更新 TiDB monitor 的版本号。
可能是因为升级之后监控指标变多了， 以前开的非常小的 Thanos sidecar 内存不够用了。
可以看到我们的 initializer baseImage 用的是我们自己打包的镜像，原因是我们希望 DM 和 TiDB 的指标用同一组 Prometheus + Grafana，而官方的 initializer 每次执行时似乎会清理掉原有的配置，所以对镜像里的脚本做了一些简单的魔改，注释掉了清理逻辑。（不知道将来官方是否可以考虑通过参数支持这个需求）
升级完毕后遇到的问题
升级完后整体上业务都没有特别的感知，但有一个我们的业务在重启后出现了无法启动的问题。
业务为 Spring Boot 应用，没有使用 Hibernate 作为数据库的 ORM 库，而是使用的 JetBrains Exposed 框架。
这个框架在进行初始化时会尝试通过访问 INFORMATION_SCHEMA 的一些系统表来验证业务内表名及字段的合法性
升级前后 TiDB 上报的 MySQL 版本发生了变化，从 5.7.x → 8.x
JetBrains Exposed 发现是 MySQL 8，尝试访问
INFORMATION_SCHEMA.KEYWORDSTiDB v7.5.2 暂时还不支持这张表
当时也在社区里查了一下这个问题，发现类似情况 https://asktug.com/t/topic/1018669，最后选择改 TiDB 参数而不去动业务了
使用 TiDB Operator 时，修改运行参数也很方便，只要直接在 CRD 对应字段里加上，等着滚动升级即可。配置完后问题即得到解决。
总结
升级后遇到的兼容性问题刚好在 TiDB v7.5.3 获得了修复，后续计划再进行一次升级，同时把手动更改的参数恢复到默认值。时间不巧，刚好没赶上。
升级完毕后，整体感觉集群运行更为稳定了。虽然遇到了 MySQL 8 的兼容性问题，但也可以看到 TiDB 正在努力兼容，这也为未来我们全面升级到 MySQL 8 打下了良好的基础。
升级过程可以说非常丝滑，全部升级大概只花了半天的时间，整个过程基本上就是看着 TiDB Operator 的日志进行操作，通过 K8S CRD 对集群的抽象配置也进一步减少了人工的介入。去年将集群全部迁移进 K8S 现在来看确实是一件非常值得的事情，一方面提高了机器资源利用率，另一方面也减轻了此后的运维压力。
后续还在升级后的集群上运行了过去的 TiSpark 任务，代码和库都没有变更，也能正常执行，应该没有产生不兼容的变化。
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/ee5cd1efed37c29c5f1279f47】。文章转载请联系作者。
TiDB 社区官网:https://tidb.net/ 2021-12-15 加入
TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目，旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/
评论