第2章 硬件选型规划

TiDB 集群的硬件要求在官方文档中进行了总结。本节将介绍更实用的硬件选择和优化。请注意,如果工作负载不同,下文的细节可能有所不同,需要根据实际情况调整。

2.1 TiDB server 组件

如果是典型的 TP 类场景,业务并发较高,但几乎都是点查点写,那么整个系统的瓶颈大概率先出现在 tidb-server,所以 tidb-server 的 cpu 高一点,数量多一点是一个更好的选择。 如果你有更多 OLAP 类的查询,内存通常会成为瓶颈。在以下情况中,可以考虑分配超过官方文档建议的 16GB 的内存:

  • 工作负载中 OLAP 查询的比例很高;
  • 工作负载中包含很复杂的 OLAP 查询;
  • 计划使用 mydumper 进行全量备份

2.2 PD 组件

主要负责全局唯一的事务号的分配,以及整个集群的元数据信息。所以 PD 不需要太多的资源,在集群规模较大,元数据较多的情况下,推荐使用 SSD 磁盘。但是 PD 的稳定性对于整个集群来说至关重要,生产环境推荐单独的服务器部署 PD,而且要有至少三个节点。对于非关键性工作负载或者非生产环境,你可以考虑将 PD 和 TiDB 组件部署在同一台服务器上,或减少 PD 实例数以降低成本。

2.3 TiKV 组件

TiKV 节点除了负责数据存储之外,也会负责部分的计算功能,通常情况下,TiKV 组件是最消耗资源的部分。为避免出现任何问题,建议你为 TiKV 多分配或预留些资源,特别是如果你预计不久后流量会大幅增加,则更应注意这一点。同时 TiKV 实例的个数必须不小于副本数(max-replicas),考虑到 location-label ,TiKV 实例个数推荐是副本数的倍数,并且应当与你的数据量/业务相关。

2.4 监控组件

在监控组件的硬件资源上,官方的建议比较大方,但实际情况你可以考虑缩小规模以节省一些硬件成本,4-8GB 内存、2-4 核 CPU 在大多数情况下已经够用了。建议不要把监控组件部署在一个 16GB 内存、8 核 CPU 的实例上,而是可以考虑部署在两个分别有 8GB 内存、4 核 CPU 的实例上,这样能保证 Prometheus/Alertmanager/Grafana 监控系统的高可用性。TiDB 后续也会推出支持监控高可用的部署方式。

2.5 Pump 组件

建议使用:

  • CPU:4 核
  • 内存:8GB
  • 磁盘:SSD
  • 网络:万兆网卡(建议两块)

Pump 非常占用磁盘和网络资源。你需要确保具有足够的磁盘空间和网络带宽,特别是如果业务不能承受较大的同步延迟,则更应注意这一点。

2.6 Drainer 组件

建议使用:

  • CPU:4 核
  • 内存:8GB
  • 磁盘:如果 Drainer 生成了文件,建议使用 SSD;其他情况无特殊要求。
  • 网络:万兆网卡(建议两块)

Drainer 主要占用很多网络资源。如果你的 Drainer 输出类型是文件,请确保具有足够的磁盘带宽,以进行准实时增量备份。

2.7 传统备份恢复

如果你计划使用 mydumper/myloader 进行备份与恢复,请确保使用具有足够磁盘和网络带宽的专用节点。建议使用:

  • CPU:16 核
  • 内存:32GB
  • 磁盘:SSD
  • 网络:万兆网卡

如果你需要压缩转储文件,则应将内存增加一倍(即 64GB)。

results matching ""

    No results matching ""