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

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

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

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

dashboard里面展示的是5.3.1

登录机器查看每个实例也是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吗？

可以看下.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也不会修改集群版本的。

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

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