Tiflash 的最小拓扑架构 问题

🪐 TiDB 技术问题
1

看文档 https://docs.pingcap.com/zh/tidb/stable/minimal-deployment-topology/ 文档里面 tidb的最小拓扑架构是

tidb * 2
pd * 3
tikv * 3
monitoring * 1

tiflash 的最小架构 https://docs.pingcap.com/zh/tidb/stable/tiflash-deployment-topology/ 变成了

tidb * 3
pd * 3
tikv * 3
tiflash * 1
monitoring * 1

tidb 最小从 2 个节点变成了 3个节点 这是为啥？如果是生产环境，能在tidb最小架构(2个tidb)基础上 扩容 一个tiflash 节点吗？

2

本身部署上，加上tiflash后，如果可以保证tidb资源使用没有瓶颈，可以不在意tidb-server变成3的情况继续使用2个
具体变化不太清楚因为啥，可能是觉得加一个tiflash，想要对应加一个tidb，将分析型查询进行隔离，专门使用一个tidb-server去支持

3

操作上可行，没什么问题

4

可以扩的

5
  • TiDB 最小拓扑（2 TiDB）：是面向开发 / 测试的最小资源配置，只保证基础功能可用，不强制要求高可用。
  • TiFlash 最小拓扑（3 TiDB）：是面向生产环境的推荐最小配置，核心是为了保证 HTAP 场景下的高可用和性能：
  1. 高可用保障：TiDB 是无状态的 SQL 计算层，部署 3 个节点可以避免单点故障，即使一个节点宕机，仍有其他节点提供服务。
  2. 负载分担：TiFlash 主要用于加速分析型查询（OLAP），这类查询对计算资源消耗较大，3 个 TiDB 节点可以更好地分担计算压力，避免性能瓶颈。
  3. 文档定义：官方文档中，包含 TiFlash 的最小拓扑是为了满足生产环境的基本要求，因此对 TiDB 节点数量的要求更高。
6

tiflash 没有也可以的

7

这才是正解

8

2个tidb节点也可以扩容tiflash节点的

9

测试环境一个宿主机就能行,我的测试环境就是一个虚拟机

10

可能是考虑让分析类业务，通过新增的 tidb 节点访问 tiflash，不影响原有业务访问其他 2个 tidb 节点吧。其实没什么关系，只要数据库延迟满足业务要求，几个tidb节点都可以。

11

tidb 一个的话，挂掉就没了，两个能保证高可用。至于3个，没什么严格要求吧，就当2个就行了。

12

一个专门的负责tiflush的tidb-server，避免tp业务和ap业务互相影响。

13

没有问题，可以扩。

14
  • 文档差异：3 TiDB 是 HTAP 生产推荐最小配置，2 TiDB 是纯 OLTP 最小配置。
  • 技术可行性：2 TiDB + 1 TiFlash 完全可以在生产环境使用，功能正常。
  • 生产建议：
  • 初期分析负载轻：直接在 2 TiDB 集群上扩容 TiFlash，快速启用 HTAP。
  • 分析负载加重：逐步将 TiDB 扩容到 3 节点，提升稳定性与 MPP 性能。
15

其实不用在意tidb是3个还是2个，可能主要目的就是拿一个tidb专门给tiflash用

16

可以，但前提是 TiKV ≥3

1 个赞
17

TiFlash 生产环境 建议上2个

18

通过 TiDB Dashboard 监控 TiDB 节点的 CPU / 内存使用率，若 OLAP 查询导致负载过高，及时扩容 TiDB 节点至 3 个

19

也能在tidb最小架构(2个tidb)基础上 扩容 一个tiflash 节点吗，视具体负载再考虑扩容

20

理论上是可以的，没啥问题