集群缩容，服务器以及磁盘空间都是足够承载缩容后的数据量的，现在是11台tikv服务器缩容到8台服务器，缩容出去3台机器，想问下，3副本缩容的过程中，迁移leader 是如何从原来的region 上迁移到其他的peer 上的，是原来的leader 失去了心跳，其他的两个follower 进行选举，选举出来一个新的leader ,如果是这样的话，目前是2个副本的，不满足3副本，是迁移完成leader 马上就去补副本吗？
- Leader 迁移：
- 当一个 TiKV 节点被缩容时，它上面的 leader 可能需要迁移到其他节点上。
- Leader 迁移的过程通常是这样的：
- 原 Leader 失去心跳：当 TiKV 节点被缩容时，原 Leader 可能会失去心跳，导致其不再被视为有效的 Leader。
- 其他 Follower 进行选举：其他两个 Follower 会开始进行选举，以选出一个新的 Leader。
- 选举新 Leader：选举过程中，TiKV 节点会相互通信，通过 Raft 算法选举出一个新的 Leader。
- 新 Leader 接管：一旦新 Leader 被选出，它会接管原 Leader 的职责，包括处理客户端请求和复制数据。
- 副本补充：
- 在缩容过程中，如果原 Leader 被迁移走，可能会导致某些 Region 的副本数不足。
- TiKV 集群会自动检测到这种情况，并尝试补充副本。
- 补充副本的过程通常是这样的：
- 检测不足的副本：TiKV 集群会检测到副本数不足的 Region。
- 选择一个合适的节点：集群会选择一个合适的节点来作为新的副本。
- 复制数据：新的副本会从其他副本中复制数据，以确保数据的一致性。
- 维护 Raft 日志：新的副本会维护 Raft 日志，以确保数据的持久性和一致性。
2 个赞
缩容过程中查看了下监控，显示leader 迁移的时间和大量产生空region 的时间对不上，leader 迁移的时间 大约比大量产生空region 的时间靠前，是不是也可以这样理解：迁移完成leader 到补副本之间不是一起进行的，先迁移完毕leader 之后，然后进行检测，检测有缺少副本的情况才会去进行补，还有一个问题是，我看有的同学缩容的时候会先手动驱逐tukv节点上的leader ,手动驱逐和等待集群自己迁移leader 有什么区别呢？
1 个赞
手动驱逐是为了让缩容时间更可控吧
缩容tikv，首先肯定是当前节点上的leader节点先迁移，补充副本会靠后一点。手工驱逐是为了先把leader驱逐掉，执行命令的时候不需要等待太长时间，免得超过默认超时时间了
是当前节点上的leader节点迁移到其它节点
Leader 副本会进行迁移。
补充副本呀
需要观察缩容的节点状态么？ 这个状态总共有几类
大哥，有没有手动吧leader驱逐的相关文档 或者命令。我找了社区和官方文档没找到。
把tikv对应的节点上的leader都驱逐到其他tikv节点，通过pd-ctl 命令
scheduler add evict-leader-scheduler 1 ：添加移除 Store 1 的所有 Leader 的调度器
1 个赞
通过使用 pd-ctl 可以查看到 TiKV Store 的状态信息。TiKV Store 的状态具体分为 Up，Disconnect，Offline，Down，Tombstone。各状态的关系如下：
- Up：表示当前的 TiKV Store 处于提供服务的状态。
-
Disconnect：当 PD 和 TiKV Store 的心跳信息丢失超过 20 秒后，该 Store 的状态会变为 Disconnect 状态，当时间超过
max-store-down-time指定的时间后，该 Store 会变为 Down 状态。 -
Down：表示该 TiKV Store 与集群失去连接的时间已经超过了
max-store-down-time指定的时间，默认 30 分钟。超过该时间后，对应的 Store 会变为 Down，并且开始在存活的 Store 上补足各个 Region 的副本。 -
Offline：当对某个 TiKV Store 通过 PD Control 进行手动下线操作，该 Store 会变为 Offline 状态。该状态只是 Store 下线的中间状态，处于该状态的 Store 会将其上的所有 Region 搬离至其它满足搬迁条件的 Up 状态 Store。当该 Store 的
leader_count和region_count(在 PD Control 中获取) 均显示为 0 后，该 Store 会由 Offline 状态变为 Tombstone 状态。在 Offline 状态下，禁止关闭该 Store 服务以及其所在的物理服务器。下线过程中，如果集群里不存在满足搬迁条件的其它目标 Store（例如没有足够的 Store 能够继续满足集群的副本数量要求），该 Store 将一直处于 Offline 状态。 -
Tombstone：表示该 TiKV Store 已处于完全下线状态，可以使用
remove-tombstone接口安全地清理该状态的 TiKV。
一楼大佬讲的很详细，佩服
这玩意不是自动的吗？
还有一个问题想问下，如果我手工stop 一个tikv实例，位于这个实例上的leader 会有迁移的动作吗？还是这个实例上的leader 死了，造成有部分数据不能读取
也就是说手工驱逐leader 是为了整个缩容的过程持续的时间更短，其实整个的流程和自动等待缩容的流程都是一样的
会迁移啊，不管是正常下线还是异常下线，只要pd连不上你的tikv节点超过一定的时间，就会默认你的tikv节点连不上，开始把其他节点上的follwer启用作为leader对外提供服务了
一样的，并且你手工驱逐的时候可以改动region和leader的迁移速度，缩短时间
谢谢，学习了
非常棒