关于升级到 v6.2.0 及以上版本时，如何解决升级卡住的问题

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
以下内容摘自官方文档： 使用 TiUP 升级 TiDB | TiDB 文档中心

升级到 v6.2.0 及以上版本时，如何解决升级卡住的问题

从 v6.2.0 开始，TiDB 默认开启并发 DDL 框架执行并发 DDL。该框架改变了 DDL 作业存储方式，由 KV 队列变为表队列。这一变化可能会导致部分升级场景卡住。下面是一些会触发该问题的场景及解决方案：

  • 加载插件导致的卡住升级过程中加载部分插件时需要执行 DDL 语句，此时会卡住升级。解决方案：升级过程中避免加载插件。待升级完成后再执行插件加载。
  • 使用 kill -9 命令停机升级导致的卡住
    • 预防措施：避免使用 kill -9 命令停机升级。如需使用，应在 2 分钟后再启动新版本 TiDB 节点。
    • 如果升级已经被卡住：重启受影响的 TiDB 节点。如果问题刚发生，建议等待 2 分钟后再重启。
  • DDL Owner 变更导致的卡住在多 TiDB 实例场景升级时，网络或机器故障可能引起 DDL Owner 变更。如果此时存在未完成的升级阶段 DDL 语句，升级可能会卡住。解决方案：
    1. 先 Kill 卡住的 TiDB 节点（避免使用 kill -9）。
    2. 重新启动新版本 TiDB 节点。

问题如下，麻烦帮忙解答下，谢谢
1、如何知道升级是卡住了还是在进行PD transfer leader 和 TiKV evict leader
2、加载插件的卡住和DDL Owner 变更导致的卡住是怎么确定的？
3、文档中提到：使用 kill -9 命令停机升级导致的卡住。kill -9的kill哪个进程，这个如何确认？
4、等待2分钟是在等待什么完成吗？

新手一枚，麻烦大神们帮忙解答下，升级卡住的话，如何解决

2

另外，我再问下，升级的时候，生产环境默认的超时时间一般能满足PD transfer leader 和 TiKV evict leader的操作吗？如果不能，–transfer-timeout 3600 设置为3600s应该可以满足了？还是有其他的建议？

3

  1. 生产环境默认的超时时间是否能满足PD transfer leader 和 TiKV evict leader的操作？

    • 生产环境中，默认的超时时间可能不足以满足PD transfer leader 和 TiKV evict leader的操作。PD leader切换的耗时通常比配置值要长不少，可能要10多秒甚至好几十秒。因此，默认的超时时间可能不足以满足这些操作。

  2. --transfer-timeout 3600 设置为3600s是否应该可以满足了？

    • 设置--transfer-timeout为3600秒应该足够满足PD transfer leader 和 TiKV evict leader的操作。这个设置允许更长的等待时间，以确保leader迁移过程有足够的时间完成，从而避免因超时而导致的升级问题。

。

4

卡了，是timeout的报错吗？

5

这是看的官方文档的时候的疑问，想更加详细的知道升级卡住后如何定位卡住的原因和处理的方法

6

你好，如何知道升级卡住后如何定位卡住的原因和以及对应的处理的方法

7

这个在升级日志里会打印的

1 个赞
8
  1. PD transfer leader 和 TiKV evict leader 分别发生在 pd 和 Tikv 各自的滚动重启阶段，文档中说的 ddl 导致的升级卡住发生在 TiDB 阶段
  2. 插件是企业版功能，社区版本不存在这个问题， ddl 变更导致的卡住 TiDB-server 会报错 [“[upgrading] get owner op failed”]
  3. kill tidb-server ，可以通过在tidb组件所在节点 ps -ef|grep tidb-server 确认进程号
  4. 等待进程完全清理干净。
1 个赞
9

插件的问题你可以不用担心，一般人用不到这个。

https://docs.pingcap.com/zh/tidb/v8.4/sql-statement-show-plugins

可以用这个语句看看当前是否存在插件。这个插件老早以前是设计用来输出一些审计日志的。而审计是个付费功能。下面是插件系统的设计文档。

所以要么你有本事自己开发这个插件，要么就是付费用户，才需要考虑存在插件的问题。

文档中一直在强调避免使用kill -9。你就别管他kill -9了什么进程了吧。不要用就好了。
看解决方法这个问题也不严重。单独重启tidb节点就好了。

这个是tiup的默认等待操作完成的时间。

https://docs.pingcap.com/zh/tidb/stable/tiup-component-cluster#--wait-timeoutuint默认-120

通过上面这个参数调节。升级的时候，还是建议调到10分钟。

1 个赞