raft leader选举时是否存在同时到达election time的情况？

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】生产\测试环境\ POC
【 TiDB 版本】
【遇到的问题】
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
【附件】

  • 相关日志、配置文件、Grafana 监控（https://metricstool.pingcap.com/)
  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview 监控
  • 对应模块的 Grafana 监控（如有 BR、TiDB-binlog、TiCDC 等）
  • 对应模块日志（包含问题前后 1 小时日志）

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

Rat论文里第5.2节有描述

Raft uses randomized election timeouts to ensure that split votes are rare and that they are resolved quickly. To prevent split votes in the first place, election timeouts are chosen randomly from a fixed interval (e.g., 150–300ms). This spreads out the servers so that in most cases only a single server will time out; it wins the election and sends heartbeats before any other servers time out. The same mechanism is used to handle split votes. Each candidate restarts its randomized election timeout at the start of an election, and it waits for that timeout to elapse before starting the next election; this reduces the likelihood of another split vote in the new election. Section 9.3 shows that this approach elects a leader rapidly.

在TiDB里面，最小选举超时时间为 raft-min-election-timeout-ticks，最大选举超时时间为 raft-max-election-timeout-ticks，在这个区间上，不同节点会随机发起选举，从而尽量避免多个节点同时发起选举而瓜分选票的情况出现，但也不是能够完全避免，一旦选票被瓜分导致无法选出Leader，会重新发起下一轮选举投票

3

但是这样选举出来的region Leader就是随机的，是否会结合TiKV节点的负载情况进行综合后选举合适的region Leader呢？

4

选举的时候不会考虑负载。比如有个TiKV节点挂了，那么Leader位于该TiKV节点上的所有Region都会各自独立的进行Raft Leader选举，大家都是随机来选举Leader，那其实这些新选出来的Leader也就随机均匀的分布到了其它所有TiKV上。后续PD再根据TiKV节点和Region的负载进行调度

5

也就是负载调度只是PD的工作

6

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。