【 TiDB 使用环境】测试/ Poc
【 TiDB 版本】7.5.1
当前标签设计为[“cloud”,“region”,“host”]，TiKV的标签为{ cloud: “aliyun”, region: “cn-beijing-a”, host: “tikv-1” }、{ cloud: “aliyun”, region: “cn-beijing-b”, host: “tikv-2” }、{ cloud: “aliyun”, region: “cn-beijing4-1”, host: “tikv-3” }类似这样的，5副本配置。
如果想实现Leader节点放在cn-beijing-a或者cn-beijing-b，cn-beijing-a副本1个或者2个，cn-beijing-b副本1个或者2个，cn-beijing4-1副本1个，请问能否实现?
我现在按文档创建了这个策略 CREATE PLACEMENT POLICY testp2 LEADER_CONSTRAINTS=“[+region=cn-beijing-a]” FOLLOWER_CONSTRAINTS=‘{“+region=cn-beijing-a”: 1, “+region=cn-beijing-b”: 2, “+region=cn-beijing4-1”: 1}’; 但是这个leader只能放在cn-beijing-a，想让leader分布在两个region中
想到一个折中的方法，不知是否能在生产使用。CREATE PLACEMENT POLICY testp1 CONSTRAINTS=‘{“+region=cn-beijing-a”:2, “+region=cn-beijing-b”: 2, “+region=cn-beijing4-1”: 1}’;，然后通过scheduler add evict-leader-scheduler store_id来驱逐，不让leader调度到cn-beijing4-1
不知能否解决问题
https://docs.pingcap.com/zh/tidb/stable/geo-distributed-deployment-topology
通过 raftstore.raft-min-election-timeout-ticks 和 raftstore.raft-max-election-timeout-ticks 为 TiKV 节点配置较大的 election timeout tick 可以大幅降低该节点上的 Region 成为 Leader 的概率。但在发生灾难的场景中，如果部分 TiKV 节点宕机，而其它存活的 TiKV 节点 Raft 日志落后，此时只有这个配置了较大的 election timeout tick 的 TiKV 节点上的 Region 能成为 Leader。由于此 TiKV 节点上的 Region 需要至少等待 raftstore.raft-min-election-timeout-ticks 设置的时间后才能发起选举，因此尽量避免将此配置值设置得过大，以免在这种场景下影响集群的可用性。
1 个赞
就是在cn-beijing4-1的store配置文件中增加选举leader的election timeout tick
效果不好，配置了这两个参数后，模拟插入数据该节点的leader数量还是在往上增加
林夕一指
(林夕一指)
10
多设置一个标签isleader不就好了 
LEADER_CONSTRAINTS=“[+isleader=1]”
1 个赞
那FOLLOWER_CONSTRAINTS改咋写，如果能保证按照2:2:1的均匀的分布呢