tiup扩容tikv时获取到旧的集群版本导致新节点无法启动

【 TiDB 使用环境】
生产环境

【 TiDB 版本】
TiDB集群版本:Server version: 5.7.25-TiDB-v5.3.1

tiup版本:Local installed version: v1.11.1
1.11.1 tiup
Go Version: go1.19.2
Git Ref: v1.11.1
GitHash: b95172df211e4f9b643590f2dd8436ad60c72b38

【复现路径】
使用tiup执行扩容新tikv实例,
执行命令:tiup cluster scale-out online1 out_tikv_20230206.yaml

【遇到的问题:问题现象及影响】
现象:执行tiup失败,且新节点报错无法启动:"version should compatible with version 5.3.1, got 4.0.6
说明:半年前我们这个集群从4.0.6升级到了5.3.1,这次扩容新节点竟然扩到了旧的版本,导致tikv起不来
影响:扩容失败

【资源配置】
【附件:截图/日志/监控】
1.[2023/02/06 14:53:38.788 +08:00] [ERROR] [util.rs:347] [“request failed”] [err_code=KV-PD-gRPC] [err="Grpc(RpcFailure(RpcStatus { status: 2-UNKNOWN, details: Some("version should compatible with version 5.3.1,

2.tiup cluster display online1 展示的集群版本是旧的版本
Cluster name: online1
Cluster version: v4.0.6

dashboard里面展示的是5.3.1
image

登录机器查看每个实例也是5.3.1。怀疑是上次升级的时候tiup这里信息没更新对

确定半年前都升级成功了?tiup cluster display一下看看

tiup cluster display online1 展示的集群版本是旧的版本
Cluster name: online1
Cluster version: v4.0.6

dashboard里面展示的是5.3.1
image

登录机器查看每个实例也是5.3.1。所以怀疑是tiup这里信息没更新

tiup cluster audit 看看之前 upgrade 的 audit log 呢, 目测是之前的 upgrade 有异常。

$ tiup cluster audit |grep upgrade

fxw5PHDyRQH 2021-01-28T01:39:16+08:00 /home/fdc/.tiup/components/cluster/v1.3.1/tiup-cluster upgrade tidbonline v4.0.6
fTQt5sbrCBF 2022-06-07T00:27:10+08:00 /home/fdc/.tiup/components/cluster/v1.9.6/tiup-cluster upgrade tidbonline v5.3.1
fTQv2V0csc7 2022-06-07T00:41:22+08:00 /home/fdc/.tiup/components/cluster/v1.9.6/tiup-cluster upgrade tidbonline v5.3.1
fTQBhcVB75L 2022-06-07T01:59:46+08:00 /home/fdc/.tiup/components/cluster/v1.9.6/tiup-cluster upgrade tidbonline v5.3.1

看最后一个id的log吗?


看起来你们尝试了三次,先看看最后一次的 log 呢, 看看有没有一些错误信息

可以看下.tiup/storage/cluster/clusters/tidbonline/meta.yaml里版本是什么

是4.0.6.

tidb_version: v4.0.6
last_ops_ver: |-
v1.3.2 tiup
Go Version: go1.13
Git Branch: release-1.3
GitHash: 2d88460

那大概率是tiup当时更新错误导致的,tiup是读取自己meta.yaml文件里的version,tidb_dashboard应该是读取的真正运行的值,两者读取源不是同一个地方。如果确认线上版本是5.3.1,可以改下tiup的meta.yaml重新部署一下

或者是tiup目录变了,执行upgrade成功后,又被谁覆盖了.tiup目录??

线上版本确认是正常的,你说的手动修改是直接vim .tiup/storage/cluster/clusters/tidbonline/meta.yaml 这个目录文件?

这个是最后这次upgrade的audit log:
tiup_from_v4.0.6_to_v5.3.1_audit_fTQBhcVB75L_20220607.log (8.6 MB)

嗯啊,不过要先确认线上各组件版本确实都已经是5.3.1了


这不是中断了么

https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup#41-升级时报错中断处理完报错后如何继续升级

感觉先把新扩容tikv节点缩容掉,然后重新replay一下上次upgrade,理论上正常升级后,meta.yaml里的version会自动改成最新值

这个是生产环境,不能随意升级,不然影响业务了。

而且感觉不是这个原因,半年前那次到最后是tiup一键升级成功了的。

你截图的这里是node_exporter的启动超时,应该不影响的。

集群的其他组件tidb、tikv、tipd都是正常升级到5.3.1了的,现在去确认版本也是对的

replay时候,会从错误的那步往下走,已经执行成功的是不会再执行的。另外如果确定好关键组件都已经升级成功,可以直接改meta.yaml文件。
PS:--wait-timeout默认超时时间是120秒,确实有点儿短,升级tikv时候必定会失败,我都是直接改成86400(24小时)

虽然node_exporter启动超时,对集群可用性没有影响,但是作为tiup cluster upgrade的一个步骤,执行失败也代表任务失败,tiup也不会修改集群版本的。

1 个赞

你说的有道理,node_exporter失败了,tiup可能是在后面才修改这个版本信息,由于tiup没有执行到最后所以导致没有更新。

按照这个说法,我可以先缩容刚4.0.6的节点,手动修改.tiup/storage/cluster/clusters/tidbonline/meta.yaml的版本,然后用新的5.3.1版本再扩容