现在啥情况了

可以删

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。

你是配置了5副本吗，把脚本输出结果 找几个region_id 在确认下，pd-ctl region xxxx 看下输出的store_id是不是全是之前处理的那些，是的话就可以 recreate , 参考下面 ：

之前下线的store 你不是已经做过unsafe recover了吗，现在是把那些在3个副本都在offline store里的region，然后把这些region recreate 后看看能否把down的tikv拉起来

down是因为暂时起不来，先不要动呢。 offline没正常缩容完你就删了目录的话，up也不好使了

down的不算，就你做过缩容、store delete 、unsafe recover的，你这些offline 还有没有数据目录没被删除的 ，哟的话 改为up状态停止缩容： curl -X POST http://:/pd/api/v1/store/<store_id>/state?state=Up

store 列表里，你先找那些你下线的 、store delete 操作的节点，之前这些不是都unsafe recover了

看你现在的操作不止是 .9 .10上做了缩容操作 .123上也做了， 在同一主机上的tikv应设置相同的label 保障同一主机上不会有相同region的副本，避免出现多副本失败的情况，你现在一下弄了这么多store 肯定有很多全副本丢失了， 多副本恢复的步骤是在 所有正常的tikv上去unsafe recover 下线的store，你先 按下面 故障节点为store id 1，5，6）： pd-ctl region --jq=".regions\[] | {id: .id, peer\_stores: \[.peers\[].store\_id] | select(length as …

你最初缩容怎么做的？ 你看前面链接文章里找下 查找3个副本都没有的 脚本，然后检查下看看有多少全丢失的region,这些得重建里面数据肯定没了

是只处理了这一个store吧，之前有缩容了几个？

前面是15698413 后面就成了34673997 ，能贴个tiup display完整输出吗

你现在看的store和前面的不一样啊，

现在什么状态？做了哪些

第三步在每个正常的tikv执行

说下你的操作过程 ，还有tiup display的完整输出

你有几个tikv，几个正常的？ 估计你这得做多副本失败恢复，把有问题的store 剔除 参考以下几个：

如果仅仅是强制下线了1个tikv节点，按理说不应该这样，他还有2个副本呢 ，你先手动添加remove peer命令，把下线节点上的peer移除。 参考下面脚本- for i in {下线store_id} do for j in pd-ctl region store $i | jq ".regions[] | {id: .id}"|grep id|awk '{print $2}' do pd-ctl operator add remove-peer $j $i done pd-ctl store $i done 然后pd-ctl 观察store的状态和region cou…

store delete id 只是把tikv变为offline状态，在此期间会转移region和leader ，之后变成tombestone状态执行tiup cluster prune就好了。 tidb报找不到region是因为 因为tikv下线 leader和region转移了，导致tidb 的region cache 失效，tidb会自动重试这是正常机制。从你的描述来看应该是之前有tikv下线没完成，现在又做了tidb server的缩容，tiup cluster display xx 先看下集群状态