【 TiDB 使用环境】线上故障
【 TiDB 版本】 5.0.6
【遇到的问题】
Tikv服务器 宕机，然后 开始region 大量增长，导致cpu资源消耗变高
5台tikv服务器，其中一台服务器发生宕机，然后region 开始疯狂增长，期间没有大量的写入。
其他节点也有增长，但没有 宕机那台机器增长的速度快
这是我当时的qps
做过哪些操作出现的问题【附件】
请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。
看看grafana上pd面板的operator，看看在干什么。
这上面还有多少 region？ 可以看下 PD 面板为什么产生这么多 region 调度。
如果是调度引起的，先把 region-schedule-limit 调小
tidb.log 中有什么异常吗？如果是非预期的 region 暴增；
看 tikv down 应该没超过 30min，不知道跟补 region 有没有关系。
看 tikv down 没超过30分钟，在10分钟左右
确实完全宕机吗？还是那种半死不活的(时不时有心跳的那种)，如果是这种，建议直接关机。
https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file#max-store-down-time 什么值？有改过吗？
先把 region-schedule-limit 调小看是否能缓解
问题已经解决， 想找一下这个根因
这不是在balanceregion吗。你总共也就几百个，balanceregion的话就是老ikv增加一个副本，新tikv删除一个副本。这样总的副本数是增加了一个。所以region数就是增加的。
看你那台说挂掉的机器，也没挂掉啊，看起来像是挂了又恢复了。一个172的ip你马赛克个什么劲啊老哥，如果推测红线都是同一台tikv的话，为啥又往这个上面增加副本也不清楚了。。。。
想知道 是不是bug，导致，如果是bug的话 ，反馈给官方。
这个节点的 tikv.log 方便拿一下吗？
tidb 的日志。 恢复之后 都在请求挂掉那台机器。。
应该是 region cache 没清，如果业务能忍，等一段时间就自愈了。
挂机的日志没有了。 tikv，但有 时间 2022/08/16 16:37:12.471 +08:00的日志
大量的
[2022/08/16 16:37:12.471 +08:00] [WARN] [region_request.go:694] [“tikv reports ServerIsBusy retry later”] [reason=“scheduler is busy”] [ctx=“region ID: 6242178, meta: id:6242178 start_key:“t\200\000\000\000\000\000\000R_i\200\000\000\000\000\000\000\014\001\000\000\000\000\000\000\000\000\367\003\200\000\000\000\006\034W\371” end_key:“t\200\000\000\000\000\000\000R_i\200\000\000\000\000\000\000\014\001JD190812\37714064854\3773228\000\000\000\000\373\003\200\000\000\000\004\036\317\247” region_epoch:<conf_ver:11621 version:2589 > peers:<id:6309747 store_id:1 > peers:<id:6313712 store_id:44598 > peers:<id:6316950 store_id:4 > , peer: id:6313712 store_id:44598 , addr: 172.26.131.17:21162, idx: 1, reqStoreType: TiKvOnly, runStoreType: tikv”]
嗯 是的 我好奇 为啥他region 会有这么大浮的增长
我以为是，恢复业务后，还一直报 cop to wrong store 呢
