Multi-Raft 分组

🪐 TiDB 技术问题
1

TiDB 的 Multi-Raft 分组，单 Store 多 Region Leader 均衡时，如何平衡 IO 与网络开销？

2

Multi‑Raft 下，PD 按 “先均衡 Leader 数、再控单 Store 负载、隔离 IO 与网络” 的原则调度；TiKV 用 Raft 批处理 + 独立 RocksDB 实例合并 IO，同时 PD 调度限速、分批迁移，把 Leader 分散到多 Store，从而平衡单 Store 的 IO 压力与 Raft 复制的网络开销。

1 个赞
3

这个问题可以看看官方文档的 FAQ，TiDB 在这块有比较详细的说明。方便的话贴一下具体的报错日志，方便大家帮忙定位。

4

不让任何一个 Store 同时承担过多 Leader、过多 I/O、过多网络流量。通过 PD 的全局负载调度、Raft 层的消息与复制优化、存储部署的硬件隔离，以及业务侧的读分流与亲和性，可在 I/O 与网络之间取得最优平衡，避免单节点瓶颈。

5

Multi-Raft 下，PD 按「先均衡 Leader 数、再控单 Store 负载」

6

依靠PD 全局调度均衡各节点 Leader 数量，分散压力；TiKV 通过 Raft 批处理、IO 合并降低开销，同时调度限速分批迁移，兼顾 IO 与网络负载。

7
  • PD 打开 IO 感知均衡、热点 Region 调度，不再单纯按 Leader 数量均分；
  • 限速 Leader 迁移速率，错峰调度避免瞬时负载冲击；
  • TiKV 开启 Raft 日志压缩、快照限流，降低单 LeaderIO 与网络消耗；
  • 硬件差异化配置 Leader 权重，热点预分裂打散压力；
  • 多 AZ 拓扑让 Leader 同机房部署，减少跨机房同步带宽损耗。
8

由 PD 的 balance-leader 调度器负责均衡
PD 采集各 Store 负载、Leader 数量，把过载节点的 Region Leader 切换到同 Raft 组其他健康副本节点，只换角色、不挪数据
可配置节点权重、调度限速，也能手动指令干预打散 Leader

9

从数据库设计角度，这类问题通常可以归结为数据模型和访问模式的匹配度问题。具体需要看你的 schema 和查询模式才能给出更针对性的建议。

10

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。