tidb版v5.0.2到v5.0.6升级问题咨询

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
生产环境
【概述】场景+问题概述
版本升级
【背景】做过哪些操作
【现象】业务和数据库现象
暂无
【业务影响】
暂无
【TiDB 版本】
v5.0.2
【附件】

  1. TiUP Cluster Display 信息

  2. TiUP Cluster Edit Config 信息

  3. TiDB- Overview 监控

  • 对应模块日志(包含问题前后1小时日志)

线上有一套v5.0.2版的tidb集群,近期计划升级到v5.0.6修复ticdc的bug,在开发和预发环境已分别验证了如下两套方案:

方案一:原地直接升级,从v5.0.2升级到v5.0.6
方案二:主从切换升级,先部署v5.0.6新版tidb,然后将旧版数据同步到新版tidb、验证一致性和调整外围配置,最后进行主从切换

我们内部进行评审讨论,觉得方案二太复杂了,偏向方案一,但对方案一的风险有些拿不准,想咨询一下大家几个问题
1、滚动升级过程中,对于tidb节点连接会中断,有多台tidb会中断多次,这个有更无损的方式吗?
2、升级过程中出现中断,就是部分组件升级成功了,部分组件升级失败,还有部分组件没有升级,看官方文档说问题修复后可以继续升级,但此刻集群还可以正常对外提供服务吗?是否可以回退?
3、升级之后一段时间出现无法解决的问题,可以整体回退吗?

您好,有2点疑问想探讨一下,

1、滚动升级过程中,对于tidb节点连接会中断

有考虑过升级过程中先将要升级的tidb server下线么?升级成功再加回集群?

部分组件升级失败

是升级时连接超时,还是什么原因?

计划采用整个集群升级,而不是部分组件分批升级,分批升级还是太麻烦了;

部分组件升级失败是我猜测的可能,可以是连接超时,或其他其他原因,比如目录权限有问题,这个在以前升级dm的时候出现过,这里主要是想表达升级过程中整个集群处于中间状态了,那此时是否对外整体可用

滚动升级过程,只对当前节点上 tidb-server正建立的连接有影响,程序都有重试机制。会切到正常的tidb-server上。
集群只支持升级,不支持降级。 升级前需要做好充分测试。同一个大版本下 小版本号越大的肯定是修复过小版本的问题。应该没啥问题。
你说的中间状态,感觉几率应该很小,没遇到过,我理解大版本号一致, 是可以正常提供服务的。 如果是跨大版本的中间状态,有新增大功能之类的,可能会有问题。

  1. 业务增加读写请求重试机制、停机窗口升级停机时间根据节点数做一下评估、如果业务有读写请求重试机制理论上对于业务影响非常小;
  2. 看是哪个组件升级失败,如果 TiDB 影响不会太大,PD 如果不是 Leader 没有影响,TiKV 如果是 3 副本且多个 tikv 实例会有 QPS 波动;
  3. 小版本升级,可以尝试整体回退。

参考文档:https://pingcap.com/zh/best-practice-detail/lossless-upgrade-of-tidb-cluster

方案二虽然复杂,但是对于响应延迟极为敏感的业务是很好的保障,建议考虑一下。

多谢解答,我们在综合考虑一下

最后采用方案二完成平稳升级

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。