【TiDB 使用环境】生产环境
【TiDB 版本】V4版本
【部署方式】机器部署
为什么pd会大规模的对tikv对region进行驱逐。目前查看集群的tikv节点 负载 io cpu都很正常，突然间pd将两个节点的tikv的leader 进行了迁移，但过了几分钟又把leader 迁移回来了。并且在这期间有一台主的CDC挂了。
看截图像是PD调度触发了leader迁移，但几分钟后又回切，大概率是这几种情况：
-
TiKV心跳异常：检查PD日志里是否有
region heartbeat超时或store down告警。CDC挂掉可能导致TiKV到PD的心跳链路抖动，PD误判节点不可用，触发驱逐。 -
调度参数问题：V4版本默认
leader-schedule-limit较高，如果PD的store-limit配置不当，网络抖动时容易误调度。
PD 短暂把两个节点的 leader 迁走又迁回，通常是心跳抖动、调度器或 store 短时间不可达，不一定是 CPU/IO 已经打满。去 PD 日志里对时间点查 evict/transfer 原因，并核对 TiKV store 状态。CDC 主节点掉线也可能是这次 region 迁移触发的 owner 重选。
- TiKV 节点之间存在大量空闲 gRPC raft 长连接，防火墙空闲超时直接把 TCP 会话踢掉；操作系统内核 2 小时之后才会探测该连接失效；
- 当 Raft 消息、Region 心跳、CDC 扫描请求需要复用这些已经死掉的 gRPC 连接的时候，报
keepalive watchdog timeout / gRPC connection could be broken； - 对端 TiKV 收不到 Raft 消息，Raft Lease 失效，Region 无法维持 Leader；PD 检测到大量 Region 汇报异常，触发批量 transfer‑leader 把 Leader 迁出该 Store；
- 注意：TiKV 进程本身完全健康，CPU/IO 正常，只是存量 gRPC 长连接已经坏掉；
- 一段时间后，Raft 重新尝试建连，gRPC 重建成功，Region 状态恢复，PD 又把 Leader 迁回原节点；
- 同一时间，TiCDC 大量依赖 tikv gRPC 连接读取 Raft changelog，大量连接报错 UNAVAILABLE，直接导致 CDC 主进程崩溃退出。
v4 版本 TiKV 的 grpc keepalive 参数默认比较保守，对中间网络设备空闲断开抵抗力弱，该故障在 v4 版本比较常见。
我看tikv日中中grpc是在发生迁移之后才报错，55分45秒左右，而发生迁移时间点事55分30秒左右，看pd的日志中其实出现了两次将同一个region迁移到212608这个store，之后开始发生了迁移region，在tikv日志中看45分有 grpc异常。
v4 版本缺陷：当更新 gc‑safe‑point RPC 超时，PD/Operator 逻辑异常，错误发起大规模 transfer‑leader 调度，把节点上 Leader 全部迁走；等待内部超时恢复，Leader 又全部迁回。
大佬，这个不升级的话 有办法规避吗？？
4.0版本太老了，就算查出来有问题是bug也不会修复了。