【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】V5.0.3
scheduler add evict-leader-scheduler
此命令的作用范围
在什么情况下生效
在什么情况下又不生效。
当前遇到的问题是
对 store 1 通过此命令迁移 出所有 region的 leader
但 当前pd 的leader节点异常，pd的leader自动切换后，此设置好像不生效了
此设置是一个内存配置，不是永久生效的么？
提供 PD 相关监控面板看下
pd异常leader节点先下线试下呢
PD 如果异常，，需要重新设置，
PD 是调度中心，PD 切换后调度指令可能会失效
建议观测 tikv 所有节点的 leader 信息是否有变化，若有变化，只需要等待即可。
驱逐节点的速度和效率，取决于集群的配置和性能，也有其他的参数可以加速驱逐。请参考！
实时生效
如果PD切换leader后 ，这个就不生效了，需要重新设置是吧
生效情况：
- 当集群中有节点负载过高，需要减轻其作为Raft leader的责任时。
- 计划对某节点进行维护（如升级、重启）前，避免服务中断风险。
- 调整集群数据分布，提高整体的读写性能和稳定性。
不生效情况：
- 目标节点（需要驱逐leader的节点）不存在或处于离线状态。
- 集群中没有其他节点可以接收额外的leader，即所有其他节点也处于高负载状态。
- TiDB集群的PD组件未正常运行，无法处理调度请求。
- 手动设置了某些特定的label规则或约束条件，导致调度器无法找到合适的节点迁移leader。
1 个赞
实时生效
应该是实时生效
非常感谢
立即生效
看看PD的信息
查看一下监控和相关日志
问题解决了吗？可否提供一下日志？
我想问的是，如果我对某个 store 用此命令设置
那后续会在什么情况下，此设置会失效，如：PD-leader切换是不是会导致它失效
我的集群未做过其它的设置，保持默认。
我用 7.5.1 版本测了一下没复现你的场景， 你可以试试手动 transfer leader 之后 通过 scheduler config evict-leader-scheduler 看下当前的调度策略
生效情况
evict-leader-scheduler 调度器在以下情况下会生效：
- 负载均衡：当某些 TiKV 节点的 leader 数量远高于其他节点时，可以通过添加
evict-leader-scheduler调度器来均衡 leader 分布，从而实现负载均衡。 - 维护操作：在进行硬件升级、软件更新或其他维护操作前，可以将 leader 从即将维护的 TiKV 节点迁移走，以确保服务的连续性和数据的可用性。
- 故障转移：当检测到 TiKV 节点存在性能问题或即将发生故障时，可以提前驱逐该节点上的 leader，以便快速切换到健康的节点。
不生效情况
evict-leader-scheduler 调度器在以下情况下可能不会生效或不需要生效：
- 节点健康：如果所有 TiKV 节点都是健康的，并且 leader 分布已经相对均衡，那么通常不需要添加
evict-leader-scheduler调度器。 - 资源限制：如果集群资源有限，频繁地迁移 leader 可能会增加网络和计算资源的负担，此时应谨慎使用
evict-leader-scheduler。 - 配置错误：如果添加调度器的命令参数设置不当，比如指定了一个错误的 TiKV 节点 ID，那么调度器可能无法正确执行驱逐操作。
在使用 evict-leader-scheduler 时，应该根据实际的集群状态和业务需求来决定是否添加以及如何配置调度器。同时，建议定期监控集群的运行状况，并根据监控结果调整调度策略，以确保集群的高效和稳定运行。
这个问题学习了，以前遇到过。重建了所有才解决。
我理解的是应该是持久化的，不可能每次切换都要重新驱逐一次store leader。当前遇到的情况应该是因为pd leader异常导致没有持久化。