【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】tidb v6.1.1
【复现路径】做过哪些操作出现的问题
缩容一个kv节点
【遇到的问题：问题现象及影响】
其他kv 节点日志 一直打印invalid store xxxx, xxxx 是被缩掉的kvid, 持续了7个多小时。
sql 延迟增加, backoff 中显示 tikv server busy
【资源配置】
【附件：截图/日志/监控】
我们重启了pd, tidb 节点后依然报错， 最后重启了所有tikv节点， 恢复了。
我们的集群是从v4.0.14 滚动升级上来的
不应该啊 缩容操作怎么做的，tiup 啥版本啊。
集群拓扑信息有吗？有几个tikv，几个tidb，方便贴出来看看吗
缩容就是store delete 命令啊， 我也觉得不应该
8个kv, 4个tidb
缩容不是 store delete，这是手动删除。
缩容是 tiup cluster scale-in
没啥区别啊，最后都是执行store delete store-id
tiup cluster display xxx
pd-ctl store 63248086
先看下状态
那 store delete 之后，有没有立马关闭对应的 tikv 节点啊。
你说的这些操作我们都做过了， 在pd中执行 store 63248086 是直接报错的找不到这个store。
我们是正常等到节点状态变成tombstone, 然后remove tombstone 之后才停止的节点
估计是哪里的cache 有问题了， 以前遇到过TiDB访问已下线的kv节点，最后也是重启解决的
你猜猜为什么官方文档中推荐，缩容tikv的操作是tiup cluster scale-in而不是 store delete
store delete 比较暴力，还是使用官方文档提供的方式正常扩缩容吧
你猜我猜不猜
store delete就算删除，tiup里也会有残留信息
还是用官方推荐的方式来
