作者： 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
kubectl replace -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.5.3/manifests/crd.yaml
我们使用 kustomize 来管理所有 K8S 上的资源，所以升级比较简单，更新掉版本号就好。
- diff --git a/tidb-admin/tidb-operator/base/kustomization.yaml b/tidb-admin/tidb-operator/base/kustomization.yaml
- index bc77f9d7f..824d79d11 100644
- --- a/tidb-admin/tidb-operator/base/kustomization.yaml
- +++ b/tidb-admin/tidb-operator/base/kustomization.yaml
- @@ -1,19 +1,19 @@
- namespace: tidb-admin
- resources: []
- # - https://raw.githubusercontent.com/pingcap/tidb-operator/v1.4.4/manifests/crd.yaml
- helmCharts:
- - name: tidb-operator
- - version: v1.4.7
- + version: v1.5.3
- valuesInline:
- scheduler:
- create: false
- timezone: "Asia/Shanghai"
- controllerManager:
- resources:
- requests:
- cpu: 10m
- memory: 128Mi
- limits:
- memory: 128Mi
- repo: https://charts.pingcap.org/
- releaseName: tidb-operator
等待新实例启动，观察日志出现类似如下的信息，代表已经完成。理论上升级 TiDB Operator 不会引起 TiDB 本身的更新，兼容性没问题的话，会直接进入 ready 的状态。
- I0815 16:12:13.182073 1 tidbcluster_control.go:71] TidbCluster: [ops/bigdata] updated successfully
- I0815 16:12:43.204827 1 tidbcluster_control.go:71] TidbCluster: [ops/bigdata] updated successfully
升级 TiDB
更新 CRD 里的 version 参数即可。 同样我们的 CRD 也是用 kustomize 管理的，所以更新版本号
- diff --git a/ops/tidb/overlays/prod/tidb.yaml b/ops/tidb/overlays/prod/tidb.yaml
- index ac8269805..1d8761a96 100644
- --- a/ops/tidb/overlays/prod/tidb.yaml
- +++ b/ops/tidb/overlays/prod/tidb.yaml
- @@ -10,7 +10,7 @@ spec:
- #######################
-
- ## TiDB cluster version
- - version: "v6.5.7"
- + version: "v7.5.2"
-
- ## Time zone of TiDB cluster Pods
- timezone: Asia/Shanghai
应用后，TiDB Operator 就会马上开始滚动升级，PD → TiKV → TiDB → TiCDC。我们线上是一个最小高可用规模的集群，大概花费半个小时左右的事件就能滚动升级完毕，消耗时间较长的是 TiKV 和 TiCDC，过程中需要迁移 leader 以保证尽可能的平滑，需要等待一些时间。
建议通过观察 TiDB Operator 日志来确定是否升级完毕
升级 DM
我们通过一组 DM 同步 MySQL 数据到 TiDB 当中，升级完 TiDB 后配套升级 DM。
同样是更新 CRD 里的 version 参数
- diff --git a/ops/tidb-dm/overlays/prod/dm.yaml b/ops/tidb-dm/overlays/prod/dm.yaml
- index dddfe1f55..a0802b168 100644
- --- a/ops/tidb-dm/overlays/prod/dm.yaml
- +++ b/ops/tidb-dm/overlays/prod/dm.yaml
- @@ -3,7 +3,7 @@ kind: DMCluster
- metadata:
- name: bigdata
- spec:
- - version: v6.5.7
- + version: v7.5.2
- configUpdateStrategy: RollingUpdate
- pvReclaimPolicy: Delete
- discovery:
DM 的升级过程相当快，基本上都可以看作是无状态的服务，重启了就好了。
建议通过观察 TiDB Operator 日志来确定是否升级完毕
升级 TiDB Monitor
更新 TiDB monitor 的版本号。
- diff --git a/ops/tidb-monitor/overlays/prod/monitor.yaml b/ops/tidb-monitor/overlays/prod/monitor.yaml
- index d9c19bfea..f7fb4ba38 100644
- --- a/ops/tidb-monitor/overlays/prod/monitor.yaml
- +++ b/ops/tidb-monitor/overlays/prod/monitor.yaml
- @@ -10,7 +10,7 @@ spec:
- - name: bigdata
- initializer:
- baseImage: ccr.ccs.tencentyun.com/patest/tidb-monitor-initializer
- - version: v6.5.7
- + version: v7.5.2
- alertmanagerURL: alertmanager.ops:9093
- kubePrometheusURL: http://k8s-prometheus.ops:9090
- thanos:
- @@ -22,7 +22,7 @@ spec:
- name: thanos-config
- requests:
- cpu: 10m
- - memory: 32Mi
- + memory: 64Mi
- version: v0.31.0
- grafana:
- baseImage: grafana/grafana
- @@ -45,7 +45,7 @@ spec:
- version: v2.45.0
- initializer:
- baseImage: ccr.ccs.tencentyun.com/patest/tidb-monitor-initializer
- - version: v6.5.7
- + version: v7.5.2
- reloader:
- baseImage: pingcap/tidb-monitor-reloader
- limits:
可能是因为升级之后监控指标变多了， 以前开的非常小的 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.KEYWORDS - TiDB v7.5.2 暂时还不支持这张表
当时也在社区里查了一下这个问题，发现类似情况 https://asktug.com/t/topic/1018669 ，最后选择改 TiDB 参数而不去动业务了
- diff --git a/ops/tidb/overlays/prod/tidb.yaml b/ops/tidb/overlays/prod/tidb.yaml
- index 1d8761a96..bcdfcefdd 100644
- --- a/ops/tidb/overlays/prod/tidb.yaml
- +++ b/ops/tidb/overlays/prod/tidb.yaml
- @@ -364,6 +364,8 @@ spec:
- ## tidb-server Configuration
- ## Ref: https://docs.pingcap.com/tidb/stable/tidb-configuration-file
- config: |
- + server-version = "5.7.44-TiDB-v7.5.2"
- +
- [log]
- [log.file]
- max-backups = 3
使用 TiDB Operator 时，修改运行参数也很方便，只要直接在 CRD 对应字段里加上，等着滚动升级即可。配置完后问题即得到解决。
总结
升级后遇到的兼容性问题刚好在 TiDB v7.5.3 获得了修复，后续计划再进行一次升级，同时把手动更改的参数恢复到默认值。时间不巧，刚好没赶上。
升级完毕后，整体感觉集群运行更为稳定了。虽然遇到了 MySQL 8 的兼容性问题，但也可以看到 TiDB 正在努力兼容，这也为未来我们全面升级到 MySQL 8 打下了良好的基础。
升级过程可以说非常丝滑，全部升级大概只花了半天的时间 ，整个过程基本上就是看着 TiDB Operator 的日志进行操作，通过 K8S CRD 对集群的抽象配置也进一步减少了人工的介入。去年将集群全部迁移进 K8S 现在来看确实是一件非常值得的事情，一方面提高了机器资源利用率，另一方面也减轻了此后的运维压力。
后续还在升级后的集群上运行了过去的 TiSpark 任务，代码和库都没有变更，也能正常执行，应该没有产生不兼容的变化。
