tikv down掉一天后，看监控regioncount归零了，一天后再次被拉了起来，该节点数据会复用down掉tikv时的历史数据，还是会重新从集群中balance过去呢？是否对集群数据一致性造成影响呢？
【TiDB 使用环境】生产环境 /测试环境
【TiDB 版本】
【部署方式】云上部署（什么云）/机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
TiKV 进程 down 多久都没事，只要磁盘数据还在，重启就是增量追日志，不重拷、不丢数据、不破坏一致性。
只挂1个tikv实例，不会对一致性有影响。tikv实例挂了之后，该实例上面的leader Region会在剩余副本中进行leader选举（因为数据写入的时候是多数派，所以剩余节点是可以选出一致性的region为leader ）。
这个得看故障了多长时间。tikv实例心跳丢失时间超过 max-store-down-time （默认 30 分钟 ）后，PD 将其标为Down，并开始把该tikv实例上相关 Region 的副本在其它存活tikv上“补齐/替换”。所以得分两种情况：
该tikv上的region会向当前leader同步缺失的Raft log；追赶完成后，它重新成为健康Region副本。
原该tikv上的region已经变成多余期副本，后续会被调度移除，那么就会触发balance。
这两个文档有提到上述场景：
https://docs.pingcap.com/zh/best-practices/pd-scheduling-best-practices/#tikv-节点故障处理策略
https://docs.pingcap.com/zh/tidb/stable/tidb-scheduling/
宕掉之后，集群如果把原来在这个tikv上的region在其他tikv上补了副本，这个tikv再起来还能追日志？没搞懂
时间就是1天呢，已经超过30min，并且集群自身已经补齐了3副本。但是一天后故障tikv又被拉起来了，是想知道，被拉起的故障tikv会继续使用磁盘上的数据，还是作为一个新的节点，从集群中balance数据过来呢？如果是继续使用磁盘上的数据，那岂不是有一部分数据变成了4副本了？（因为集群在tikv故障期间补了一个副本）
我觉得补齐副本之后，这个tikv再拉起来就是当做一个新的节点用了。
故障期间已经补齐了3副本，那么故障tikv实例上的region就不会被使用了。
这种应该比较合理
我也觉得这样是合理的
重启后的 TiKV 节点优先复用本地已有的历史数据
不会复用本地历史数据，而是全量从集群中同步（balance）缺失的数据。
需要关注PD的调度策略,决定了tikv故障恢复的过程
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
