TiDB 集群规划最佳实践

TiDB 集群规划是确保集群高效、可靠运行的基础。本文将详细介绍 TiDB 集群规划的最佳实践，包括架构设计、硬件选择、网络规划、容量规划和部署模式。

架构设计

1. 组件角色规划

组件	角色功能	部署建议
TiDB	SQL 层，处理客户端请求	2-5 个节点，根据并发量扩展
TiKV	存储层，数据持久化	3-100+ 个节点，根据数据量扩展
PD	调度层，集群管理	3 或 5 个节点，奇数个确保高可用
TiFlash	列式存储，OLAP 加速	1-3 个节点，根据分析需求扩展
TiCDC	变更数据捕获，实时同步	1-3 个节点，根据同步需求扩展

2. 拓扑结构设计

单数据中心部署

适用于对容灾要求不高的场景：

跨数据中心部署

适用于对容灾要求较高的场景：

3. 副本策略设计

默认配置：3 个副本，分布在不同节点
跨可用区部署：副本分布在不同可用区，配置 replication.location-labels = ["zone", "rack", "host"]
跨数据中心部署：副本分布在不同数据中心，根据距离调整副本优先级
特殊场景：对数据安全性要求极高的场景，可配置 5 个副本

硬件选择

1. TiDB 服务器

配置项	建议配置	说明
CPU	16-32 核	高并发场景建议 32 核
内存	64-128 GB	内存越大，SQL 执行缓存效果越好
磁盘	SSD 1-2 TB	主要存储日志和临时文件
网卡	10 GbE 或更高	确保网络带宽充足

2. TiKV 服务器

配置项	建议配置	说明
CPU	16-32 核	建议使用高主频 CPU
内存	64-256 GB	内存越大，RocksDB 缓存效果越好
磁盘	NVMe SSD 2-8 TB	推荐使用 NVMe SSD，单盘容量不宜过大
网卡	25 GbE 或更高	确保副本同步和数据迁移速度

3. PD 服务器

配置项	建议配置	说明
CPU	8-16 核	PD 计算需求相对较低
内存	16-64 GB	内存越大，元数据缓存效果越好
磁盘	SSD 500 GB-1 TB	存储集群元数据，建议使用 SSD
网卡	10 GbE 或更高	确保与其他组件通信顺畅

4. TiFlash 服务器

配置项	建议配置	说明
CPU	32-64 核	分析查询对 CPU 要求较高
内存	128-512 GB	内存越大，列式存储缓存效果越好
磁盘	SSD 4-16 TB	推荐使用 NVMe SSD，容量根据数据量规划
网卡	25 GbE 或更高	确保数据同步和查询速度

网络规划

1. 网络架构

三层网络架构：核心层、汇聚层、接入层
网络隔离：生产环境建议使用独立的 VLAN
带宽规划：根据节点数量和数据量规划足够的带宽
延迟要求：TiKV 节点之间延迟建议 < 1 ms，PD 节点之间延迟建议 < 500 μs

2. 端口规划

组件	默认端口	用途
TiDB	4000	MySQL 协议端口
TiDB	10080	HTTP API 端口
TiKV	20160	TiKV 服务端口
TiKV	20180	TiKV 状态端口
PD	2379	PD 客户端端口
PD	2380	PD 节点间通信端口
TiFlash	9000	TiFlash 服务端口
TiFlash	8123	TiFlash HTTP 端口
TiFlash	3930	TiFlash MySQL 端口
TiFlash	20170	TiFlash Raft 端口
TiCDC	8300	TiCDC HTTP 端口

3. 网络优化

关闭防火墙：生产环境建议关闭防火墙或开放必要端口
禁用 SELinux：避免不必要的安全限制
优化 TCP 参数：调整 TCP 缓冲区大小、超时时间等
使用 RDMA：高性能场景可考虑使用 RDMA 网络

容量规划

1. 数据量估算

总存储容量 = 原始数据量 × 副本数 × 2 (压缩和索引开销) × 1.5 (预留空间)

2. 节点数量规划

TiDB 节点：根据并发连接数和 QPS 规划，每节点支持约 1000-2000 并发连接
TiKV 节点：根据数据量规划，每节点支持约 5-10 TB 数据
PD 节点：固定 3 或 5 个节点
TiFlash 节点：根据分析查询需求规划，通常为 TiKV 节点数的 1/3-1/2

3. 扩展性规划

水平扩展：支持在线水平扩展，无需停机
垂直扩展：支持在线垂直扩展，部分组件需要重启
扩展策略：制定清晰的扩展触发条件和流程

部署模式

1. 物理机部署

适用场景：对性能要求极高的生产环境

优势：

更高的性能和资源利用率
更稳定的运行环境
更好的硬件控制

劣势：

部署和维护成本较高
资源弹性较差

2. 虚拟机部署

适用场景：对资源弹性要求较高的场景

优势：

资源弹性好，支持快速扩容缩容
部署和维护成本较低
更好的资源隔离

劣势：

性能比物理机略低
依赖虚拟化平台

3. Kubernetes 部署

适用场景：云原生环境或需要高度自动化管理的场景

优势：

高度自动化的部署和管理
优秀的资源弹性和扩展性
更好的故障自愈能力
支持混合云部署

劣势：

学习曲线较陡
依赖 Kubernetes 生态
性能开销略高

配置规划

1. 系统配置

操作系统：推荐使用 CentOS 7.6+ 或 Ubuntu 18.04+
文件系统：推荐使用 ext4 或 xfs
磁盘调度器：SSD 推荐使用 noop 或 none
内存管理：调整 vm.swappiness 为 0，关闭透明大页
网络参数：调整 TCP 缓冲区大小、超时时间等

2. 组件配置

TiDB 配置

toml

[server]
max_connections = 8000

[log]
level = "info"

[performance]
txn-total-size-limit = 1073741824
stmt-count-limit = 5000

TiKV 配置

toml

[server]
grpc-concurrency = 8

[storage]
enable-pre-handle = true

[raftstore]
raftdb-max-bg-flushes = 2
raftdb-max-bg-compactions = 4

[rocksdb]
max-background-jobs = 8
max-open-files = 40960

PD 配置

toml

[schedule]
leader-schedule-limit = 4
region-schedule-limit = 20
replica-schedule-limit = 64
max-replicas = 3
location-labels = ["zone", "rack", "host"]

监控与告警规划

1. 监控架构

Prometheus：部署至少 2 个节点，实现高可用
Grafana：部署至少 2 个节点，使用负载均衡
Alertmanager：部署至少 2 个节点，实现高可用
Node Exporter：每个服务器部署一个

2. 关键告警指标

组件	关键告警指标	阈值建议
TiDB	连接数	> 80% 最大连接数
TiDB	SQL 执行错误率	> 0.1%
TiDB	慢查询数	> 10 个/分钟
TiKV	磁盘使用率	> 80%
TiKV	Raft 日志落后	> 1000
TiKV	CPU 使用率	> 80%
PD	Leader 切换频率	> 3 次/小时
PD	集群 Region 数	增长率异常
系统	服务器 CPU 使用率	> 85%
系统	服务器内存使用率	> 90%

3. 告警级别

Critical：严重告警，需要立即处理，如节点故障
Warning：警告告警，需要关注，如资源使用率过高
Info：信息告警，仅作参考，如配置变更

备份与恢复规划

1. 备份策略

全量备份：每天或每周执行一次，使用 BR 工具
增量备份：每小时或每 30 分钟执行一次，使用 TiCDC 或 binlog
备份存储：备份数据存储在独立的存储系统，如对象存储
备份验证：定期验证备份数据的完整性和可恢复性

2. 恢复策略

RTO 目标：根据业务需求设置，通常为分钟到小时级
RPO 目标：根据业务需求设置，通常为秒到分钟级
恢复演练：定期进行恢复演练，验证恢复流程
多版本备份：保留多个版本的备份数据，防止逻辑错误

安全规划

1. 访问控制

用户认证：启用 MySQL 原生认证或 LDAP 认证
权限管理：遵循最小权限原则，定期审计权限
IP 白名单：配置允许访问的 IP 地址范围
SSL/TLS：启用 SSL/TLS 加密通信

2. 数据安全

数据加密：启用传输加密和存储加密
敏感数据处理：对敏感数据进行脱敏或加密存储
审计日志：启用审计日志，记录所有操作
漏洞扫描：定期进行漏洞扫描和安全评估

3. 操作安全

变更管理：所有配置变更和升级操作需要经过审批
操作审计：记录所有管理操作
灾难恢复：制定详细的灾难恢复计划
定期演练：定期进行灾难恢复演练

常见问题（FAQ）

Q1: 如何选择 TiDB 集群的部署模式？

A1: 选择部署模式应考虑以下因素：

性能要求：物理机 > 虚拟机 > Kubernetes
资源弹性：Kubernetes > 虚拟机 > 物理机
管理复杂度：物理机 > 虚拟机 > Kubernetes
成本：物理机 > 虚拟机 > Kubernetes（公有云）
技术栈：根据团队的技术栈选择合适的部署模式

Q2: TiKV 节点的磁盘容量多大合适？

A2: TiKV 节点的磁盘容量建议：

单盘容量不宜过大，推荐 2-8 TB
每节点建议使用 1-4 块磁盘
预留足够的空间，建议使用率不超过 80%
考虑数据增长趋势，预留 3-6 个月的增长空间

Q3: 如何规划 TiDB 集群的网络带宽？

A3: 网络带宽规划建议：

单节点网络带宽：TiDB 节点建议 10 GbE，TiKV 节点建议 25 GbE
集群总带宽：根据节点数量和数据量规划
跨数据中心部署：考虑数据同步和副本复制的带宽需求
预留足够的带宽，避免网络成为瓶颈

Q4: 如何设置合理的告警阈值？

A4: 设置告警阈值应考虑：

业务需求：根据业务的重要性和敏感度设置
历史数据：分析历史数据，找出正常范围
资源利用率：通常设置为 80-85% 资源使用率
告警频率：避免设置过低的阈值导致告警风暴
分级告警：设置不同级别的告警阈值

Q5: 如何规划 TiDB 集群的扩展性？

A5: 扩展性规划建议：

水平扩展优先：TiDB 设计为水平扩展架构，优先考虑水平扩展
提前规划：根据业务增长趋势，提前规划扩展策略
测试扩展流程：定期测试扩展流程，确保可以顺利扩展
监控容量：设置容量告警，及时发现容量瓶颈
考虑成本：平衡扩展成本和业务需求

Q6: 如何确保 TiDB 集群的安全性？

A6: 确保集群安全性的建议：

启用多层安全防护：认证、授权、加密、审计
定期进行安全审计和评估
及时更新版本，修复安全漏洞
制定详细的安全应急预案
对团队成员进行安全培训

通过遵循以上最佳实践，可以构建一个高效、可靠、安全的 TiDB 集群，满足业务的需求。

TiDB 集群规划最佳实践 ​

架构设计 ​

1. 组件角色规划 ​

2. 拓扑结构设计 ​

单数据中心部署 ​

跨数据中心部署 ​

3. 副本策略设计 ​

硬件选择 ​

1. TiDB 服务器 ​

2. TiKV 服务器 ​

3. PD 服务器 ​

4. TiFlash 服务器 ​

网络规划 ​

1. 网络架构 ​

2. 端口规划 ​

3. 网络优化 ​

容量规划 ​

1. 数据量估算 ​

2. 节点数量规划 ​

3. 扩展性规划 ​

部署模式 ​

1. 物理机部署 ​

2. 虚拟机部署 ​

3. Kubernetes 部署 ​

配置规划 ​

1. 系统配置 ​

2. 组件配置 ​

TiDB 配置 ​

TiKV 配置 ​

PD 配置 ​

监控与告警规划 ​

1. 监控架构 ​

2. 关键告警指标 ​

3. 告警级别 ​

备份与恢复规划 ​

1. 备份策略 ​

2. 恢复策略 ​

安全规划 ​

1. 访问控制 ​

2. 数据安全 ​

3. 操作安全 ​

常见问题（FAQ） ​

Q1: 如何选择 TiDB 集群的部署模式？ ​

Q2: TiKV 节点的磁盘容量多大合适？ ​

Q3: 如何规划 TiDB 集群的网络带宽？ ​

Q4: 如何设置合理的告警阈值？ ​

Q5: 如何规划 TiDB 集群的扩展性？ ​

Q6: 如何确保 TiDB 集群的安全性？ ​

TiDB 集群规划最佳实践

架构设计

1. 组件角色规划

2. 拓扑结构设计

单数据中心部署

跨数据中心部署

3. 副本策略设计

硬件选择

1. TiDB 服务器

2. TiKV 服务器

3. PD 服务器

4. TiFlash 服务器

网络规划

1. 网络架构

2. 端口规划

3. 网络优化

容量规划

1. 数据量估算

2. 节点数量规划

3. 扩展性规划

部署模式

1. 物理机部署

2. 虚拟机部署

3. Kubernetes 部署

配置规划

1. 系统配置

2. 组件配置

TiDB 配置

TiKV 配置

PD 配置

监控与告警规划

1. 监控架构

2. 关键告警指标

3. 告警级别

备份与恢复规划

1. 备份策略

2. 恢复策略

安全规划

1. 访问控制

2. 数据安全

3. 操作安全

常见问题（FAQ）

Q1: 如何选择 TiDB 集群的部署模式？

Q2: TiKV 节点的磁盘容量多大合适？

Q3: 如何规划 TiDB 集群的网络带宽？

Q4: 如何设置合理的告警阈值？

Q5: 如何规划 TiDB 集群的扩展性？

Q6: 如何确保 TiDB 集群的安全性？