排查到原因： tikv region不上报心跳到pd，在v5.4.2版本中，有已知的bug：https://github.com/tikv/tikv/issues/12934 尝试着重启pd，重新选择pd leader后，scheduler 开始工作了 集群升级至v5.4.3后，暂时无发现异常出现

所有节点日志都看了一遍，其中有一个节点日志报错不太一样get snapshot failed [2023/05/22 19:29:29.641 +08:00] [INFO] [scheduler.rs:517] ["get snapshot failed"] [err="Error(Request(message: \"EpochNotMatch current epoch of region 233969 is conf_ver: 209 version: 19544, but you sent conf_ver: 209 version: 19315\" epoch_not_match …

从tikv日志来看，出现大量的check leader failed，这些错误都是tikv到tiflash [2023/05/22 16:16:33.795 +08:00] [INFO] [advance.rs:295] ["check leader failed"] [to_store=1580508] [error="\"[rpc failed] RpcFailure: 12-UNIMPLEMENTED\""] [2023/05/22 16:16:34.800 +08:00] [INFO] [advance.rs:295] ["check leader failed"] [to_stor…

从监控上看leader、region均未就行balance，是否需要做pd切换？

tidb duration 监控 [image]

如大佬所言，按照正常的扩缩容方式解决问题👍

store信息 { "store": { "id": 4, "address": "xxxxxx:port", "labels": [ { "key": "host", "value": "host1" } ], "version": "5.4.2", "status_address": "xxxxxx:port", "git_hash": "0d22a1b74abbf54ae259b498f6584dd26365fed2", "start_timestamp": 16…

单机多实例部署，按照官方，配置了labels config: server.labels: host: host1 另外，down掉的store上，我并没有找到所有down副本数量大于正常副本数量的所有 region，以下结果为空 region --jq=".regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(4,5,918726) then . else empty end) | length>=$total-length) }…

3台物理机9个TiKV，宕机一台物理机3个TiKV，我查过了，没有确实副本的region [image] 没有确实副本的region [image] 等region补齐后，store会从down变成 tombstone状态？

store的状态是在 pd 中是down，时间上已经超过了max-store-down-time 默认的30min，从监控看，集群已经开始在存活的store上补足各个region的副本 这些down节点上肯定有非leader region，怎么能把store从集群中剔除掉

down，我现在需要把这些移除集群，需要设置手动设置为tombstone?

的确如此，老 PD 下线过程如下： 在新 PD 加入到集群之后，为了让 TiKV 识别到新的 PD ，需要依次重启 TiKV 确认方式：在 TiKV 机器上查看 –pd 参数是否已经有了新的PD地址 $ ps -ef | grep tikv-server 下线老的 PD 节点，通过缩容 scale-out 方式 TiKV 清理老 PD 信息 重启所有的 TiKV 疑问：为啥有新 PD 加入到集群后，TiKV 客户端感知不到

意思就是我要恢复老的PD节点？

背景： 3台物理机，每台上面各有一个PD、TiKV、TiDB，其中一台是TiUP中控机（它宕机挂掉，无法恢复） 集群拓扑是：3PD + 3TiKV + 2TiDB 恢复过程： 准备工作：未对TiUP中控机做备份，根据仅存的节点拼接出了集群的topology.yaml，在deploy之后，display看到了有2个PD，2个TiKV 存活 对PD扩容，发现新扩容的节点起不来，于是按照官方的方式采用PD-Recovery进行恢复 对TiKV进行扩容，这步非常顺利 试着拉TiDB，起不来，查看日志发现有[“load mysql.user fail”] [error=“[planner:10…

我用了另外一种思路： 新建了一套集群 PD和TiKV都是正常的，就用BR做了full backup，restore新集群

是三台物理机，每台上面都组件各有一个，刚好挂掉又是tiup中控机

我在看看吧

数据还是蛮重要的，不然就重建了