reload失败,是什么原因引起的

  Still waitting for 47 store leaders to transfer...
  Still waitting for 39 store leaders to transfer...
  Still waitting for 39 store leaders to transfer...
  Still waitting for 39 store leaders to transfer...
  Still waitting for 39 store leaders to transfer...
Restarting instance 1.1.1.1.58:2000

Error: failed to restart: 1.1.1.1.58 tikv-2000.service, please check the instance’s log(/usr/local/server/tikv-2000/log) for more detail.: timed out waiting for port 2000 to be started after 2m0s

[2023/12/25 13:55:21.904 +08:00] [INFO] [apply.rs:2204] [“exec ConfChangeV2”] [epoch=“conf_ver: 12982 version: 17”] [kind=Simple] [peer_id=9895] [region_id=9888]
[2023/12/25 13:55:21.904 +08:00] [INFO] [apply.rs:2385] [“conf change successfully”] [“current region”=“id: 9888 start_key: 78000000732F436CFF65616E65724C6F63FF6B00000000000000F8 end_key: 78000000732F6563FF612D746573742F6DFF6F6E69746F725F67FF6C6F62616C2F3130FF332E3231332E3936FF2E3138365F737461FF7475730000000000FA region_epoch { conf_ver: 12983 version: 17 } peers { id: 9892 store_id: 4 } peers { id: 9895 store_id: 1 } peers { id: 14001 store_id: 10 }”] [“original region”=“id: 9888 start_key: 78000000732F436CFF65616E65724C6F63FF6B00000000000000F8 end_key: 78000000732F6563FF612D746573742F6DFF6F6E69746F725F67FF6C6F62616C2F3130FF332E3231332E3936FF2E3138365F737461FF7475730000000000FA region_epoch { conf_ver: 12982 version: 17 } peers { id: 9892 store_id: 4 } peers { id: 9895 store_id: 1 } peers { id: 9916 store_id: 7 role: Learner } peers { id: 14001 store_id: 10 }”] [changes=“[change_type: RemoveNode peer { id: 9916 store_id: 7 role: Learner }]”] [peer_id=9895] [region_id=9888]

reload失败,但看日志最终应该是成功的,会是什么原因呢

display 看一下集群状态呢?

日志是 /usr/local/server/tikv-2000/log 的日志么?

1 个赞

是的/usr/local/server/tikv-2000/log/tikv.log,集群状态都是up

  1. reload tikv 是会等 tikv leader 调度循环重启tikv的, 相关参数是 transfer-timeout ,默认是2分钟,如果超过两分钟没有调度完,那就会直接重启对应的tikv
  2. 从你发的报错是尝试重启的时候对应的 tikv 节点没有启动,可以tiup cluster display 看下对应的 tikv 节点状态

image

全是up状态

redload应该成功了,只是提示你驱逐leader没完全做完

那就没有问题,我遇到过这种情况,就是启动特别慢,超过了超时时间没有启动成功,前端会报错超时,但后台还是在继续启动的,只要最终集群状态是up就没问题。

1 个赞

但是其他机器,还没reload的,唉

遇到这台机器,重试的几次,都是比较慢导致失败,应该怎么看到底是什么原因慢

可以指定 --transfer-timeout 为一个更大的值,或者–force

Error: failed to get leader count 1.1.1.40: metric tikv_raftstore_region_count{type=“leader”} not found
还有报这种错误的

集群内如果有一台机器宕机之类的,是不是很容易出现region leader 出问题,pd 起不来,日志如下:

[2023/12/25 14:47:12.122 +08:00] [ERROR] [client.go:172] [“region sync with leader meet error”] [error=“[PD:grpc:ErrGRPCRecv]rpc error: code = Canceled desc = context canceled: rpc error: code = Canceled desc = context canceled”]
[2023/12/25 14:47:46.643 +08:00] [ERROR] [client.go:172] [“region sync with leader meet error”] [error=“[PD:grpc:ErrGRPCRecv]rpc error: code = Canceled desc = context canceled: rpc error: code = Canceled desc = context canceled”]

驱逐leader太慢,超时了,可以加个timeout参数

使用–force参数,有成功么?

Error: failed to restart: 1.1.1.1.58 tikv-2000.service,

这个就是报错的原因。确认一下对应节点的日志内容,看看有无异常信息

超时了,加个参数

看这里,https://docs.pingcap.com/zh/tidb/v6.5/tiup-component-cluster-reload#--transfer-timeoutuint默认-600

这个得看几个节点几副本吧,低于半数节点宕机,只遇到过一次pd无法启动的情况。

1 个赞

RELOAD超时,但结果是成功的,只是说明RELOAD期间有超时现象,但最终执行成功了