成功之后，然后又把这个新扩容的 7748745185 store 又缩容掉了吗？在我们上面拿的 store_result 里面没有看到这个 store，可以使用 tiup cluster audit 命令确认下历史的操作记录， tiup cluster audit {audit-id} 可以看到当时操作的 tiup log ~
现在需要先将 store 302321060 正常拉起，避免频繁重启，并且能够正常上报心跳到 PD。
我这里先内部确认下，有进度会及时跟帖回复 ~
在提出解决方案前，请不要强制关停下架服务器
目前无法正常拉起，起来之后，会自动重启。
tiup cluster audit fJnrZ8TsHCB
tiup cluster audit fJnrXNnW5PL
辛苦将上述两个 audit 中的结果分别输出到两个文件中，并上传
现在的情况是 --force 缩容了 store 302321060，其进程以及 data-dir 都被清理掉了，在状态未变为 tombstone 时，然后 scale-out 了新的 store 7748745185， 因为使用了与 store 302321060 相同的 ip 和 port，导致 scale-out 后，一直处于不断重启的状态。请将 7748745185 store 的 tikv 实例 stop 掉，然后再使用下述命令检查下集群中是否存在没有 leader 的 region 信息：
1、不存在 leader 的 region
pd-ctl -u http://ip:port region --jq '.regions[]|select(has("leader")|not)|{id: .id, peer_stores: [.peers[].store_id]}'
2、使用 tikv-ctl 命令，检查下，在 store 302321060 上的 region 状态：
1）tiup ctl:v5.0.0 pd -u pd_ip:pd_port region store 302321060 获取当前其上的 region 信息：
2）根据获取的 region 信息，使用 tikv-ctl 检查 3~4 个 region 的状态：
比如获取的 region 为：region 451990729，451990890，451990991：
{
"id": 451990729,
"start_key": "7480000000000000FFBC5F698000000000FF0000010419AAA0FAFFC000000003800000FF02EC537D9A000000FC",
"end_key": "7480000000000000FFBC5F698000000000FF0000010419AAA0FBFFC000000003800000FF02EC6F32C0000000FC",
"epoch": {
"conf_ver": 9443,
"version": 1182
},
"peers": [
{
"id": 451990730,
"store_id": 302321062
},
{
"id": 451990731,
"store_id": 302321060
},
{
"id": 451990732,
"store_id": 49878450
}
],
"leader": {
"id": 451990731,
"store_id": 302321060
},
"written_bytes": 0,
"read_bytes": 0,
"written_keys": 0,
"read_keys": 0,
"approximate_size": 0,
"approximate_keys": 0
},
{
"id": 451990890,
"start_key": "7480000000000000FFBC5F698000000000FF0000010419AAA0FCFF4000000003800000FF02EC80D244000000FC",
"end_key": "7480000000000000FFBC5F698000000000FF0000010419AAA0FDFF4000000003800000FF02EC9224BE000000FC",
"epoch": {
"conf_ver": 9443,
"version": 1184
},
"peers": [
{
"id": 451990891,
"store_id": 302321062
},
{
"id": 451990892,
"store_id": 302321060
},
{
"id": 451990893,
"store_id": 49878450
}
],
"leader": {
"id": 451990892,
"store_id": 302321060
},
"written_bytes": 0,
"read_bytes": 0,
"written_keys": 0,
"read_keys": 0,
"approximate_size": 0,
"approximate_keys": 0
},
{
"id": 451990991,
"start_key": "7480000000000000FFBC5F698000000000FF0000010419AAA0FDFF4000000003800000FF02EC9224BE000000FC",
"end_key": "7480000000000000FFBC5F698000000000FF0000010419AAA0FEFF4000000003800000FF02ECA729BD000000FC",
"epoch": {
"conf_ver": 9443,
"version": 1185
},
"peers": [
{
"id": 451990992,
"store_id": 302321062
},
{
"id": 451990993,
"store_id": 302321060
},
{
"id": 451990994,
"store_id": 49878450
}
],
"leader": {
"id": 451990993,
"store_id": 302321060
},
"written_bytes": 0,
"read_bytes": 0,
"written_keys": 0,
"read_keys": 0,
"approximate_size": 0,
"approximate_keys": 0
}
使用 tikv-ctl 到非 store 302321060 的任意两个 peer 所在的 store 上执行，以 region 451990991 为例，可以到 store 49878450 或 store 302321062上获取相应的 region 信息：
https://docs.pingcap.com/zh/tidb/stable/tikv-control#查看-raft-状态机的信息
----------------两条命令执行结果---------
tiup cluster audit fJnrZ8TsHCB
结果：
audit_fJnrZ8TsHCB.txt (3.9 KB)
tiup cluster audit fJnrXNnW5PL
结果：
audit_fJnrXNnW5PL.txt (515.4 KB)
如果允许数据丢失一部分，有没有快速的恢复方案？
这个操作结果辛苦拿下：
1、stop 掉用相同 ip:port 扩容的 store，有可能在使用相同的 ip:port 扩容后，导致 pd 误以为，原 store 302321060 仍然是存活的，stop 后，再 pd-ctl store 看下 所有 store 的信息，比如原 store 302321060 的心跳上报是否正常
2、使用 tikv-ctl 命令，检查下，在 store 302321060 上的 region 状态：
1）tiup ctl:v5.0.0 pd -u pd_ip:pd_port region store 302321060 获取当前其上的 region 信息：
2）根据获取的 region 信息，使用 tikv-ctl 检查 3~4 个 region 的状态：
使用 tikv-ctl 到非 store 302321060 的任意两个 peer 所在的 store 上执行，以 region 451990991 为例，可以到 store 49878450 或 store 302321062上获取相应的 region 信息：
https://docs.pingcap.com/zh/tidb/stable/tikv-control#查看-raft-状态机的信息
3、快速恢复的方法，这边在内部确认中，稍等 ~
目前kill掉 store 7748745185所在服务器的进程之后，会自动重启，然后又自动挂掉，一直重复。
pd-ctl里面没有看到store 7748745185的信息。
请问，现在怎么彻底将这个store 7748745185给停掉呢？
用 systemctl 来停止下这个 tikv 的 service 看下呢？
另外，根据之前提供的信息可见，在 9 月 22 号 --force ，缩容了 store 302321060，在 11 月 10 日缩容了 302321061，并且当前集群中存在 130 个 region 的两个副本分布在 store 302321060 和 store 302321061 上，并且在 --force 302321060 后的很长一段时间 region 和 leader 没有调度到其他 store，此时，又缩容了 store 302321061：
cat region.txt | jq '.regions[] | {id: .id, peer_stores: [.peers[].store_id] | select(length as $total | map(if .==(302321060,302321061) then . else empty end) | length>=$total-length) } | .id' | wc -l
130
恩，第二次缩容store 302321061，是因为这个磁盘快被占满了，4T的盘只剩几个G了，为了防止磁盘满，所以缩容了。这个目前也处于pending offline的状况，不再进行了。
辛苦用 pd-ctl 查下 region 451994156 ，451991544 、452112479 的副本分布情况~
region 451994156 除 --force scale-in 的 store 外，还有 peer 451994157 （ store 294807901），以及 peer （store 49878451） 在这两个 store 上也分布了副本，理论上会在这两个副本中产生一个新 leader。辛苦确认下：
region 451991544 以及 region 452112479 同理。
» region 451994156
{
{
"id": 451994157,
"store_id": 294807901
},
{
"id": 451994158,
"store_id": 302321060
},
{
"id": 451994159,
"store_id": 49878451
}
}
» region 451991544
{
{
"id": 451991545,
"store_id": 294807901
},
{
"id": 451991546,
"store_id": 302321060
},
{
"id": 451991547,
"store_id": 49878451
}
}
» region 452112479
{
{
"id": 452112480,
"store_id": 302321062
},
{
"id": 452112481,
"store_id": 302321060
},
{
"id": 452112482,
"store_id": 49878450
}
}
1、两个store的状态都是up
store状态.txt (1.9 KB)
2、两个store之间网络无异常，可达。
3、store 294807901 和 store 49878451 上对应region 451994156的log信息
store_294807901_region_451994156.txt (169.7 KB) store_49878451_region_451994156.txt (3.3 KB)
已在沟通处理中，问题的最终结论会在问题处理完毕后，更新~
请问处理结果如何 最后下线成功了吗 怎么操作的呢
对于 tikv 节点下线，先通过 pd-ctl 手动驱逐 leader，再进行下线，效果会更好
成功了。在老师们的帮助下成功了。说是region损坏导致的，这边官方老师给了一个修复脚本。修复了下就好了。
ok，谢谢。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。