描述的问题情况比较复杂，我只能说可能会丢失部分数据，想要恢复集群的状态，可以尝试用
unsafe recover 的方案
参考下这个实践：
https://asktug.com/t/topic/183387
2 个赞
unsafe必须关闭tikv节点并重启吗
1 个赞
我看到别人有做这个unsafe导致tikv实例起不来的问题
1 个赞
这个操作是有风险的，建议在测试环境先演练一下，
按照正常的情况，副本是不会丢失的，只需要把坏掉的节点移除掉，扩容新的节点就可以了
如果副本丢失的话，就只能这样了 
1 个赞
副本肯定是有一个正常的副本的
1 个赞
我确实搞不懂啊
像这样一个有问题的region
它里面有三个peer
其中 peerid在store274840上
peerid 504772在store2上
peerid在764540store752142上
其中274840，752142是已经不存在的store,store2是正常工作的store,像这个store2上的副本应该是正常的。
他们之间不是也有心跳吗，如果274840跟752142不应该已经没了，他这个peer为什么还是这么固执的不删掉，删掉了不是跟tikv手动删除store是一样的吗。
» region 504769
{
“id”: 504769,
“start_key”: “7480000000000026FFCF5F698000000000FF0000010000000000FA”,
“end_key”: “7480000000000026FFCF5F698000000000FF0000030380000004FF0D68C9F100000000FB”,
“epoch”: {
“conf_ver”: 26,
“version”: 7654
},
“peers”: [
{
“id”: 504771,
“store_id”: 274840
},
{
“id”: 504772,
“store_id”: 2
},
{
“id”: 764540,
“store_id”: 752142
}
1 个赞
为什么为什么为什么，这2个store都没了 他还是不删掉这2个peer,不自动转移到其他的里面
1 个赞
最可恶的是手动用命令operator add remove-peer 504769 274840这样的命令，他竟然还是要去连已经不存在的274840这个store。
这个274840不是已经没了吗，为什么还要去连
1 个赞
我们在测试环境执行了 unsafe-recover remove-fail-stores
这样重启tikv实例，tikv集群恢复正常了。
经过观察发现，执行unsafe-recover remove-fail-stores，会让store里面失效的peer删除，然后因为我们是2个store失效了，那些处于offline-peer状态的region,会把剩下的单个peer提升为leader,然后再通过make-up-replica补足三个副本，这样全部完成后集群状态就正常了
请问有没有办法不通过unsafe-recover remove-fail-stores，使用其他的手动的方法补足副本 修复tikv集群正常
1 个赞
过半副本丢失，现在只能这样恢复了，因为过半副本丢失，所以这些 region 数据可能会存在部分丢的
1 个赞
在一个 raftgroup 中，默认 3 副本，当两副本异常不可用，那么无法满足大多数。相当于 3 副本，丢失 2 副本。此时，剩余的 peer 无法自动成为 leader，无法对外提供服务。PD 也无法通过调度，来自动的在其他存活，且满足调度条件的 store 上补齐副本：关于 raft 以及 multi-raft 的描述见：
https://docs.pingcap.com/zh/tidb/stable/tidb-best-practices/#raft
https://pingcap.com/zh/blog/the-design-and-implementation-of-multi-raft
遇到这样的问题，需要通过 unsafe-recover remove-fail-stores 手动修复，在 v5.3.0 版本提供了 online 实验功能，简化处理的复杂度，见：
https://docs.pingcap.com/zh/tidb/stable/online-unsafe-recovery
最后，在同时缩容两个节点时，建议先检查是否有同一个 region 的两个 peer 都在被缩容的 store 上，避免问题的再次发生。如果无法确认，那么建议一个一个 store 的缩容，在被缩容 store 变为 tombstone 后，再缩容下一个 store，缩容过程中，如果速度较慢，那么可以参考下述文档调整对应参数：
https://docs.pingcap.com/zh/tidb/stable/pd-scheduling-best-practices/#节点下线速度慢
4 个赞
因为我们的表都是分日期创建的，比如说有些region损坏影响的表是20210831这样 之前的表，如果后面把这个表直接drop了，这些有问题的region会自动删除吗
1 个赞
比如，目标表 test_20220214 表，默认 3 副本，其有若干个 region 丢失 2 副本，那么，drop 表理论上无法操作成功。你那里可以在测试环境，验证观察下结果 ~
额。那些表以及有问题的region只能永远的留着了？
如果不用Unsafe-recover remove-fail-stores的话
是的，在多数派丢失的情况下，需要先修复，再删除 ~
没有办法手动删除吗
之前看到有个remove peer 这个操作，但是这个是要pd跟store通信的。
如上所说，不能，remove-peer 的命令不适用你现在这个丢失多副本的场景，这个命令适用于 raftgroup 健康的场景。如果要修复，需要用 unsafe-recovery，如果考虑 online 修复，那么可以在线下环境测下 v5.3.0 的 online 修复的试验特性。
当然，如果你那里下线的 2 个 store 仍然是 offline 状态，并且服务器和数据目录均在，那么可以使用下面的命令先把节点的状态修改为 UP，终止 store 的下线操作，避免 2 副本丢失的问题。建议在测试环境验证下:
curl -X POST http://${pd_ip}:2379/pd/api/v1/store/${store_id}/state?state=Up
unsafe-recovery这个操作可以在tikv集群一台一台执行吗