在宿主机因为硬件故障的情况下导致无法启动，在业务上已经保证了有至少3个副本的情况下，如何将故障机器上面的tikv节点需要直接从集群中移除？
前提： TiKV 节点有 label 标签。由于不可空的原因导致机器宕机，也就是 一个 TiKV 节点或者多个 TiKV down 掉（属于同一个 label）。
数据可用性 允许此机器的数据丢失。
有以下两个方法参考
-
因数据 3 副本，可不用人工干预，30 minutes 后该 TiKV 节点会被踢出Cluster。
-
出于要立刻将此 TiKV 节点踢出 Cluster 的目的。可使用如下步骤：
2.1) 在剩余健康的 TiKV 节点，逐个停掉 TiKV 服务（可使用PingCAP Ansible 提供的脚本 stop/start_tikv.sh）
2.2) 执行 tikv-ctl --db {db目录} unsafe-recover remove-fail-stores -s {store_id} --all-regions，该命令会将 down 掉的 TiKV 上的 region peer 全部 delete 。
2.3) 启动所有健康的 TiKV 节点。
第一个方案
30mins后，cluster剔除，那么从pd ctl查看到的store是 down状态，怎么清理掉这些信息？
第二个方案
有不用停止tikv节点的方法吗？个人觉得，需要一种方法标记失效kv节点为丢失了，pd能够通知其他tikv节点，重新副本的复制以及自动处理失效kv节点的peer ，这块有在做不？
30mins 后，down 的节点就会被强制清理。 现在的信息上报的机制是 TiKV 上报给 PD，这是为了避免 TiKV 的短时间故障导致 PD 将其踢出的场景。
看官方文档的说法，tikv 会跟 pd 进行心跳包，Raft Group 的 Leader 和 PD 之间也存在心跳包， 用来检测健康状态以及PD 做策略，请问这个心跳包多久发一次呢？这个时间能不能自己设置？ 能不能设置连续几次没收到就下掉，而不是不能人工干预苦苦等待 30 分钟呢？
region 到 PD 默认是 60s 发送一次心跳，用来做 region 健康检查，这个时间在 tikv.yml -> pd-heartbeat-tick-interval 设置这个参数来调整。因为 TiDB 默认是三副本，所以即使一个节点 down 掉也不会影响数据的完整性，另外也因为多节点所以会比较依赖网络质量，如果网络出现短暂异常，PD 短暂获取不到 region 心跳而下掉节点，不太合理。 另外在等待 30 分钟期间，集群还是可用的，不影响正常使用。
官网文档摘取：PD 不断的通过这两类心跳消息收集整个集群的信息，再以这些信息作为决策的依据。除此之外，PD 还可以通过管理接口接受额外的信息，用来做更准确的决策。比如当某个 Store 的心跳包中断的时候，PD 并不能判断这个节点是临时失效还是永久失效，只能经过一段时间的等待（默认是 30 分钟），如果一直没有心跳包，就认为是 Store 已经下线，再决定需要将这个 Store 上面的 Region 都调度走。但是有的时候，是运维人员主动将某台机器下线，这个时候，可以通过 PD 的管理接口通知 PD 该 Store 不可用，PD 就可以马上判断需要将这个 Store 上面的 Region 都调度走。
问题：按照官方所说，我机器已经挂了的话，PD 怎么调度这个 store 的 region 呢？？
经个人推测，也在微信群跟官方人员询问后得知是这样的： 当一个 store 挂掉，PD 是知道挂掉的是哪个 store，并且这个 store 上有哪些 region，PD 是有信息的，所以 PD 就能把这些 region 重新划分到其他的 store。实现新的负载均衡和高可用。
2 个赞
数据有3个副本，只有三个TiKV节点，down掉一个TiKV， 30分钟后也会被强制清理吗？这样的话副本数量就不够啦，怎么办？
如果是三个 TiKV 节点，数据默认为三副本的时候，一个 TiKV 节点宕机，且在 30 分钟内没有起来，会开始自动补副本，最终数据还是三副本。
只剩两个TiKV节点了，数据的副本也能补成三个？ 这样的话就会出现一个TiKV节点中有一个Region的两个副本了。允许这样的情况发生吗？
这个要分情况，如果在挂掉之后能及时处理拉起来节点就不会出现两副本数据在一个节点的情况，如果一直没有处理，只剩下两个节点，为了保证数据的三副本，就会出现一个节点两副本数据的情况。
1 个赞
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。