TiDB 生产环境部署至少需要 3 台服务器以实现组件高可用，测试环境可单节点运行。生产场景必须保证 PD 组件奇数节点和 TiKV 多副本，否则存在单点故障风险。

命令速用版

部署前需在每台服务器执行硬件检查，确认资源达标。

# 检查 CPU 核心数
lscpu | grep ^CPU\(s\)

# 检查内存大小
free -h

# 检查磁盘 IO 性能（示例 /data 盘）
fio -filename=/data/fio_test -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=4 -runtime=60 -group_reporting -name=iops-test-job

# 检查时间同步
timedatectl status

为什么会这样

TiDB 架构依赖 PD 进行元数据管理与调度，依赖 TiKV 存储数据，两者均需多副本保证高可用。

PD 组件基于 Raft 共识算法，需要奇数节点（通常 3 节点）才能容忍单节点故障并完成选举。TiKV 数据默认 3 副本存储，若服务器少于 3 台，无法在单机故障时保证数据不丢失且服务可用。单节点部署仅适用于功能验证，无法满足生产容灾要求。

分步处理

按资源规划、环境检查、部署实施三步执行，避免后期扩容困难。

1. 资源规划

生产环境建议每台服务器配置 8 核 CPU 及以上、16GB 内存及以上，磁盘必须使用 SSD 或 NVMe SSD。网络建议万兆互联，避免带宽瓶颈影响分布式事务性能。

2. 环境检查

确保所有节点时间同步（NTP/Chrony），关闭防火墙或开放必要端口（如 2379, 2380, 4000, 20160 等）。文件系统建议采用 xfs 或 ext4，关闭 Swap 分区以避免内存交换导致性能抖动。

3. 部署实施

使用 TiUP 工具进行部署，编写 topology.yaml 文件明确各组件分布。避免将 PD 与 TiKV 部署在同一台机器上，除非资源极度受限且接受性能损耗。

tiup cluster deploy mycluster v7.5.0 ./topology.yaml `--user` root -p

怎么验证是否生效

部署完成后通过 TiUP 命令和监控面板确认集群健康状态。

# 查看集群状态，所有组件应为 Up 状态
tiup cluster display mycluster

# 查看 PD 成员状态，确认有 3 个成员
curl http://<pd-ip>:2379/pd/api/v1/members

# 登录 TiDB 查看 TiKV 存储状态
mysql -h <tidb-ip> -P 4000 -u root -e "SHOW STORES;"

登录 Grafana 监控面板，确认 No Critical Alerts，且 QPS、延迟指标在基线范围内。

常见坑

• 磁盘 IO 不足：使用机械硬盘或云盘低 IO 规格会导致 TiKV 写入阻塞，生产环境必须测试磁盘 FIO 性能。
• 时间不同步：集群节点间时间偏差过大会导致 PD 选举失败或事务异常，必须配置 NTP。
• 混合部署风险：在 3 台机器上混合部署所有组件虽可行，但故障域未隔离，单机电源故障可能导致整个集群不可用。
• Swap 未关闭：Linux 默认开启 Swap，内存压力大时交换到磁盘会引发严重性能下降，建议永久关闭。

常见问题

测试环境可以用 1 台服务器吗？

可以，但仅限功能验证。

单节点部署无法模拟高可用切换，不能用于性能测试或生产数据验证，数据丢失风险极高。

云服务器部署有什么特殊要求？

需确保云盘 IO 性能达标且网络内网互通。

建议使用独占型实例，避免共享型实例因邻居噪声导致性能波动，安全组需放开集群内部通信端口。

PD 组件为什么必须是奇数台？

为了满足 Raft 共识算法的多数派选举要求。

3 节点可容忍 1 台故障，4 节点同样只能容忍 1 台故障且增加成本，因此生产环境通常部署 3 台 PD。

参考来源

• PingCAP 官方文档 - 硬件和软件需求：https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements
• PingCAP 官方文档 - 生产环境部署建议：https://docs.pingcap.com/zh/tidb/stable/production-deployment-guide