【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.8
【遇到的问题：问题现象及影响】TIKV 单个副本故障【假如一台物理机器损坏】的修复手段，从官方文档上没找到具体的操作流程，对于这个场景，哪位大神可以提供个SOP操作步骤呢，我这边大致的想法如下，不知道是否准确，辛苦各位大神指导。
1、tiup display出来故障的TIKV节点
2、通过某种状态【目前还未知】，使用tiup踢掉这个故障TIKV节点
3、重新初始化一台服务器【基础环境prepare】，编辑好scale in的配置
4、tiup scale注册上去
5、观察新TIKV节点数据恢复进度等信息
单个副本，kv故障就死了啊，生产环境应该至少3副本吧
第2步后面增加一个：
通过 pd-ctl 执行个store delete
1、tiup display出来故障的TIKV节点
2、重新初始化一台服务器，编辑好scale out的配置,扩容节点
3、观察新TIKV节点数据恢复进度等信息
4、强制缩掉故障节点 tiup cluster scale-in xxx --node 故障的TIKV节点 --force
楼上说的没错，要先扩容在缩容，一定要保证tikv正常的节点数大于3，然后再对有问题的tikv节点缩容。
参考：
先扩后缩即可
我们tikv节点是3个，多备份吧
RAFT协议，三个可以挂一个
从操作上看OK，需要具体步骤了，我看有兄弟提供官方文档了，我先看看
这篇文当写的非常详细，我先仔细拜读一下，感谢朋友
这篇文当写的非常详细，我先仔细拜读一下，感谢
具体步骤就是楼上说的呀，这两个文章我也看了，以你现在的情况，第一个文章只是说了要先扩容在缩容，第二个文章中的宕机1台的情况，也没有具体的步骤，说的是原理及注意事项。
我其实比较关心的是，新增后等数据都同步完毕后在释放损坏的副本，那个损坏的副本是不是有状态呢，有没有可能在一些状态下释放不了呢
可以pd-ctl工具看下，这个节点上是否还有leader 没有迁移完毕，如果leader 的数量为0，说明数据是无损的
region如果是百万级别的量级，估计leader的迁移时间确实会比较长
是的，只能等着leader 迁移完毕才能对有问题的节点做操作，不然会出现数据丢失的问题，我们之前有一次是测试环境，leader 还没有迁移完毕，节点出现问题异常down 掉了，导致有部分leader没有来得及迁移完毕
当机器故障一定时间后，对于集群来说，这个机器上的副本已经是不可用的状态了，所以现在集群里只有两个副本。扩容的时候，集群会在新节点上补充副本，使集群保持三副本的状态。最后缩容的时候，需要加上 --force ，强行缩容故障集群上的节点，所以不会出现释放不了的情况
三副本丢了一个副本，不管丢失的副本是不是leader，也不会影响数据吧。况且扩容节点之后还会自动补充副本数。leader也会自动均衡