三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

TiDB分布式数据库从零部署实战：架构解析与生产级配置指南

发布时间：2026/8/5 10:03:02 三亩地 编程学习日记
TiDB分布式数据库从零部署实战：架构解析与生产级配置指南

1. 项目概述：为什么选择TiDB？

最近在规划一个需要处理海量交易和实时分析混合负载的新项目，数据库选型成了团队讨论的焦点。传统方案无非是“MySQL分库分表”或者“业务拆分成OLTP和OLAP两套系统”，前者开发运维成本高得吓人，后者又带来了数据一致性和同步延迟的麻烦。就在我们纠结时，TiDB这个“分布式NewSQL数据库”进入了视野。它号称兼容MySQL协议，能水平扩展，同时支持在线事务处理（OLTP）和在线分析处理（OLAP）。听起来很美好，但到底是不是“银弹”？最好的验证方式就是亲手把它装起来，跑一跑，压一压。这篇文章，我就把从零开始部署一套TiDB测试集群的完整过程、踩过的坑以及一些关键配置的理解，毫无保留地记录下来。无论你是想评估TiDB，还是单纯对分布式数据库的部署运维感兴趣，这篇近万字的实操笔记都能给你提供一份可靠的参考。

2. 部署架构设计与组件解析

在真正动手敲命令之前，我们必须先理解TiDB的架构。盲目安装只会导致后续运维的灾难。TiDB集群主要包含四个核心组件，它们各司其职，共同构成了一个完整的分布式数据库系统。

2.1 核心组件分工与协作

TiDB Server：这是集群的“大脑”和“门面”。它本身不存储数据，主要负责接收SQL请求，进行解析、优化，生成分布式执行计划。它完全兼容MySQL协议和语法，你的应用程序可以像连接MySQL一样连接TiDB Server。你可以部署多个TiDB Server实例来实现负载均衡和高可用。

PD Server (Placement Driver)：这是集群的“调度中心”和“元数据管理者”。它是整个TiDB集群的中枢神经系统，主要负责两件事：一是存储整个集群的元数据（如表、索引的分布信息）；二是对TiKV集群进行调度和负载均衡，包括Region（数据分片）的迁移、副本的增删、Leader选举等。PD通常需要部署奇数个节点（如3个）以通过Raft协议保证高可用。

TiKV Server：这是集群的“肌肉”和“仓库”，负责实际的数据存储。它是一个分布式的、支持事务的键值存储引擎。数据以Region为单位（默认约96MB-144MB）在多个TiKV节点间切分和复制。TiKV使用Raft共识算法来保证数据的一致性和高可用性（通常每个Region有3个副本）。所有写入和读取最终都落在TiKV上。

TiFlash：这是一个可选的列式存储引擎，可以看作TiKV的“分析加速器”。它通过异步复制TiKV的行存数据，并将其转换为列存格式。当执行复杂的分析查询时，TiDB优化器可以智能地将查询下推到TiFlash，利用列存的高压缩比和向量化计算能力，极大提升分析性能，同时避免了对OLTP业务的干扰。

这四者的关系可以简单理解为：应用连接TiDB，TiDB向PD询问数据在哪里，然后去对应的TiKV读写数据。当需要跑分析报表时，TiDB会去找TiFlash。

2.2 生产与测试环境架构选型

理解了组件，接下来就要规划部署架构。这主要取决于你的资源和使用场景。

1. 生产环境部署（推荐）对于生产环境，高可用和性能是首要考虑。你必须遵循以下原则：

  • 组件分离部署：TiDB、PD、TiKV、TiFlash（如果使用）必须部署在不同的物理机或虚拟机上。绝对禁止将所有组件混部在同一台机器，否则单个节点的硬件故障（如磁盘损坏）会导致多个核心组件同时失效，极大增加数据丢失风险。
  • 多副本与奇数PD：TiKV和TiFlash的数据副本数至少设置为3，并分散在不同机架或可用区。PD节点必须为奇数个（3，5，7），这是Raft协议选举领导者的要求。
  • 硬件推荐：
    • TiDB：需要较强的CPU和内存，因为要处理SQL计算。建议16核+ 32GB内存起步，网络带宽要高。
    • PD：对CPU和内存要求相对不高，但需要低延迟、高IOPS的SSD磁盘来存储元数据，保证调度速度。建议8核+ 16GB内存 + NVMe SSD。
    • TiKV：这是资源消耗大户。需要高性能CPU、大内存（用于缓存RocksDB）、以及最重要的——高性能NVMe SSD。TiKV的写入性能严重依赖磁盘的IOPS和延迟。建议32核+ 64GB内存 + 多块NVMe SSD（做RAID 10或直接使用）。
    • TiFlash：对CPU和内存要求高，磁盘需要大容量SSD或高速SAS盘，因为列存查询是IO密集型。

2. 测试/开发环境部署对于学习、功能验证或开发测试，我们通常采用“单机多实例”的部署方式，也就是在一台配置还不错的机器上，模拟出一个小型集群。这是我们本次部署采用的方式。

  • 优点：资源要求低，部署简单，适合快速验证。
  • 缺点：无法体现真正的分布式性能和高可用能力，单点故障会导致整个集群不可用。
  • 硬件最低要求：一台至少8核16GB内存、拥有100GB以上空闲磁盘空间（最好是SSD）的Linux服务器。我使用的是CentOS 7.9的虚拟机。

注意：无论哪种部署，都必须确保服务器之间时钟同步（使用NTP服务），节点间网络通畅且延迟低（最好在1ms以内），并关闭防火墙或配置好相应端口规则。这是分布式系统的生命线。

3. 实战部署：使用TiUP一键搭建集群

官方推荐的部署和管理工具是TiUP，它类似于Python的pip或Node.js的npm，极大地简化了TiDB的运维工作。我们从零开始。

3.1 系统准备与TiUP安装

首先，登录你的Linux服务器，以root或具有sudo权限的用户操作。

步骤1：检查及配置系统参数这些参数优化了数据库运行环境，特别是对于TiKV的性能至关重要。

# 1. 关闭透明大页 (THP)，它可能导致数据库性能抖动 echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # 为使重启生效，需将上述命令写入 /etc/rc.local # 2. 调整文件打开数和进程数限制，编辑 /etc/security/limits.conf，在文件末尾添加： # * soft nofile 1000000 # * hard nofile 1000000 # * soft stack 10240 # * soft nproc unlimited # 修改后需要重新登录会话生效。 # 3. 确认NTP服务正在运行，保证时间同步 systemctl status ntpd 或 systemctl status chronyd

步骤2：安装TiUPTiUP的安装非常简单，一条命令搞定。

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

执行后，脚本会提示你需要将TiUP添加到环境变量。按照提示执行类似source ~/.bashrc的命令即可。

步骤3：安装TiUP的cluster组件TiUP本身是一个包管理器，管理TiDB集群需要专门的cluster组件。

tiup cluster

如果是第一次使用，TiUP会提示你安装cluster组件，输入y确认即可。

3.2 编写拓扑配置文件

这是部署中最关键的一步，它定义了集群的“蓝图”。我们在一台机器上部署一个最小化的测试集群：1个TiDB，1个PD，1个TiKV。在用户家目录下创建一个文件topology.yaml。

# topology.yaml global: user: "tidb" # 建议创建一个专门的tidb用户来运行服务 group: "tidb" deploy_dir: "/tidb-deploy" # 组件二进制文件部署目录 data_dir: "/tidb-data" # 组件数据存储目录 pd_servers: - host: 192.168.1.100 # 替换为你的服务器IP client_port: 2379 # PD客户端通信端口 peer_port: 2380 # PD节点间通信端口 tidb_servers: - host: 192.168.1.100 port: 4000 # TiDB服务端口，类似MySQL的3306 status_port: 10080 # TiDB状态查询端口 tikv_servers: - host: 192.168.1.100 port: 20160 # TiKV服务端口 status_port: 20180 # TiKV状态查询端口 monitoring_servers: - host: 192.168.1.100 node_exporter_port: 9100 # 系统指标采集端口 blackbox_exporter_port: 9115 grafana_servers: - host: 192.168.1.100 port: 3000 # Grafana监控界面端口 alertmanager_servers: - host: 192.168.1.100 web_port: 9093 cluster_port: 9094

关键配置解析：

  • user/group：强烈建议创建非root用户运行服务，提升安全性。你需要提前执行groupadd tidb && useradd -g tidb tidb并确保该用户对部署目录和数据目录有读写权限。
  • deploy_dir和data_dir：前者存放程序文件，后者存放核心数据（如TiKV的RocksDB数据文件）。务必确保data_dir所在的磁盘有足够空间和高性能（SSD）。
  • 端口规划：端口冲突是部署失败常见原因。请确保上述端口（如4000, 2379, 20160, 9090, 3000等）在服务器上未被占用。你可以用netstat -tunlp | grep <端口号>检查。

3.3 执行部署与初始化

配置文件准备好后，就可以开始自动部署了。

步骤1：检查拓扑配置

tiup cluster check ./topology.yaml --user root -p

-p参数表示在检查过程中自动修复一些可修复的系统配置问题（如limits.conf）。根据提示输入root密码。这一步会检查SSH互信、端口、目录权限等，必须所有检查项通过。

步骤2：部署集群

tiup cluster deploy tidb-test v7.5.0 ./topology.yaml --user root -p
  • tidb-test：你为这个集群起的名字。
  • v7.5.0：要部署的TiDB版本号，建议使用较新的稳定版。
  • --user root：指定在目标机器上执行部署操作的用户，需要有sudo权限来创建目录和安装服务。
  • -p：同样，在部署过程中交互输入root密码。

TiUP会从镜像站下载所有组件二进制包，分发到目标服务器，并完成初始配置。这个过程视网络情况需要几分钟。

步骤3：启动集群

tiup cluster start tidb-test

启动成功后，你会看到各个组件状态变为Up。

步骤4：验证集群状态

# 查看集群整体状态 tiup cluster display tidb-test # 更详细的状态信息 tiup cluster list

如果一切正常，你应该能看到TiDB, PD, TiKV等所有服务的状态都是“Healthy”或“Up”。

3.4 连接测试与基本操作

现在，集群已经跑起来了。我们来验证一下。

步骤1：连接TiDB数据库使用MySQL客户端直接连接TiDB的4000端口。

mysql -h 192.168.1.100 -P 4000 -u root

连接成功后，你会看到熟悉的MySQL提示符。执行几个命令试试：

-- 查看版本，确认是TiDB SELECT VERSION(); -- 创建一个测试数据库和表 CREATE DATABASE test_tidb; USE test_tidb; CREATE TABLE user ( id BIGINT AUTO_RANDOM PRIMARY KEY, name VARCHAR(100), email VARCHAR(255), INDEX idx_name (name) ); -- 插入一些测试数据 INSERT INTO user (name, email) VALUES ('张三', 'zhangsan@example.com'), ('李四', 'lisi@example.com'); -- 查询数据 SELECT * FROM user;

至此，一个最基本的TiDB集群已经部署并运行成功。

步骤2：访问监控面板TiUP在部署时自动集成了Prometheus和Grafana。在浏览器中访问http://<你的服务器IP>:3000，默认用户名和密码都是admin。Grafana里预置了丰富的监控仪表盘，可以查看集群性能、资源使用情况、SQL延迟等，这是运维的“眼睛”，一定要熟悉。

4. 生产级考量与进阶配置

测试集群跑通了，但离生产可用还有距离。下面讲几个关键的生产级配置点。

4.1 安全加固与权限管理

默认安装的TiDB，root用户密码为空，监听在0.0.0.0，这非常危险。

1. 设置root密码并限制访问：

-- 在MySQL客户端内执行 ALTER USER 'root' IDENTIFIED BY 'YourStrongPassword123!'; -- 建议创建一个仅限本地监听的超级用户，用于管理 CREATE USER 'admin'@'127.0.0.1' IDENTIFIED BY 'AnotherStrongPassword!'; GRANT ALL PRIVILEGES ON *.* TO 'admin'@'127.0.0.1';

2. 配置TiDB监听地址：修改拓扑文件中的TiDB配置部分，重启生效。

tidb_servers: - host: 192.168.1.100 port: 4000 status_port: 10080 config: # 只监听内网IP，不暴露在公网 socket: 192.168.1.100:4000 # 或者，如果应用与TiDB同机，可以只监听本地回环 # socket: /tmp/tidb.sock # 使用Unix Socket更安全

3. 启用TLS加密传输：对于生产环境，TiDB各组件间（TiDB-TiKV， TiKV-PD）以及客户端到TiDB的连接，都应启用TLS加密。这需要准备证书并在拓扑配置中为每个组件指定证书路径。步骤稍复杂，需参考官方文档生成CA和组件证书。

4.2 性能调优关键参数

默认配置适合起步，但针对特定负载需要调整。

TiKV关键参数（tikv.config）:

tikv_servers: - host: 192.168.1.100 port: 20160 config: storage: # Block Cache大小，建议设置为系统总内存的30%-50% block-cache-size: "4GB" raftstore: # 处理Raft消息的线程池大小，通常设置为CPU核数的75% apply-pool-size: 4 store-pool-size: 4 coprocessor: # 协处理器线程数，处理计算下推请求 region-worker-size: 8

调整这些参数需要结合监控指标（如Grpc message duration、Storage command duration）来判断瓶颈在哪里，切忌盲目修改。

PD关键参数（pd.config）:

pd_servers: - host: 192.168.1.100 config: schedule: # 控制Region调度的速度，负载高时可适当调低 leader-schedule-limit: 8 region-schedule-limit: 2048 replica-schedule-limit: 64

4.3 备份与恢复策略

没有备份的数据库是在“裸奔”。TiDB推荐使用BR (Backup & Restore)工具进行分布式备份，它比逻辑备份（mysqldump）更快，且保证一致性。

全量备份到S3兼容存储：

tiup br backup full \ --pd "192.168.1.100:2379" \ --storage "s3://your-bucket/backup-20231101/" \ --send-credentials-to-tikv=true \ --s3.endpoint="https://s3-endpoint" \ --s3.access-key="your-access-key" \ --s3.secret-key="your-secret-key"

从备份恢复：

tiup br restore full \ --pd "192.168.1.100:2379" \ --storage "s3://your-bucket/backup-20231101/"

对于生产系统，需要制定“全量+增量”的备份策略，并定期进行恢复演练。

5. 常见问题排查与运维心得

部署和运维过程中，难免会遇到问题。这里分享几个典型场景和排查思路。

5.1 部署阶段典型问题

问题1：tiup cluster check失败，提示SSH连接错误。

  • 排查：确认部署用户（如root）是否配置了到目标机器的免密登录（SSH公钥认证）。使用ssh root@目标IP手动测试。
  • 解决：在部署机上生成SSH密钥对（ssh-keygen -t rsa），并将公钥（~/.ssh/id_rsa.pub）内容添加到目标机器的~/.ssh/authorized_keys文件中。

问题2：组件启动失败，状态一直为Down或Unhealthy。

  • 排查：使用tiup cluster audit tidb-test查看操作日志，或直接查看组件日志。日志路径通常在<deploy_dir>/log下。
    # 查看TiKV的日志 tail -f /tidb-deploy/tikv-20160/log/tikv.log
  • 常见原因：
    • 端口冲突：日志中可能有Address already in use错误。用netstat找出占用端口的进程并处理。
    • 目录权限不足：确保tidb用户对deploy_dir和data_dir有读写权限。
    • 内存不足：TiKV启动需要较多内存，如果系统内存不足，可能会被OOM Killer杀掉。查看系统日志/var/log/messages。

5.2 运行阶段性能与稳定性问题

问题3：写入或查询速度慢。

  • 排查思路：
    1. 看监控：首先打开Grafana。
      • TiDB Dashboard->SQL语句分析：查看慢查询，分析执行计划。
      • TiKV->Details：关注Storage command duration和Grpc message duration。如果write或read的P99延迟很高，可能是磁盘IO瓶颈。
      • TiKV->Raft IO：查看Propose wait duration和Append log duration，过高可能意味着Raft日志写入慢。
    2. 查磁盘：在服务器上使用iostat -x 1查看磁盘使用率（%util）和响应时间（await）。如果%util持续接近100%，说明磁盘已是瓶颈。
    3. 查热点：在TiDB Dashboard的热点区域页面，查看是否有某个Table或Region的读写流量远高于其他，这可能导致单个TiKV节点过载。

问题4：TiKV节点频繁重启或离线。

  • 排查：查看该TiKV节点的日志，重点搜索panic、error、signal等关键词。
  • 常见原因：
    • OOM (Out Of Memory)：TiKV的block-cache-size或raftstore相关内存配置过大，导致系统物理内存耗尽。需要调低参数或增加机器内存。
    • 磁盘空间满：data_dir所在的磁盘被写满。TiKV需要预留约20%的磁盘空间用于Compaction等后台操作。
    • 磁盘故障：硬件问题导致IO错误。需要检查磁盘SMART状态。

5.3 日常运维心得与技巧

  1. 变更操作先在测试集群演练：无论是版本升级、参数调整还是扩缩容，务必先在和生产环境架构类似的测试集群上操作一遍，观察监控，确认无误后再在生产环境进行。TiUP的cluster upgrade、cluster scale-in/out等命令很好用，但也要谨慎。

  2. 善用TiDB Dashboard：除了Grafana，TiDB内建的Dashboard（默认在TiDB的10080端口，如http://<tidb_ip>:10080/dashboard）是更强大的运维利器。它的SQL语句分析、慢查询、热点区域、集群诊断功能非常直观，定位问题往往比直接查日志更快。

  3. 容量规划要提前：不要等到磁盘快满了才想起来扩容。监控好TiKV的存储容量和Region数量。单个TiKV实例管理的Region数量不宜过多（通常建议低于5万）。当容量或Region数接近阈值时，就要考虑通过tiup cluster scale-out增加TiKV节点了。

  4. 理解“调度”：TiDB的弹性来自于PD的调度。如果发现负载不均衡，不要急于手动干预。先观察PD的调度操作（在Dashboard或监控里看），理解其调度逻辑（如热点调度、均衡调度）。大多数情况下，PD能自动处理好。频繁的手动转移Region可能会干扰PD的正常调度。

这套从零开始的部署流程和运维要点，是我在多次搭建和测试TiDB集群后总结出来的。分布式数据库的引入确实会带来一定的运维复杂度，但TiDB通过TiUP等工具已经极大地降低了门槛。对于需要处理增长迅猛的业务、同时又希望简化技术栈的团队来说，花时间深入理解和掌握TiDB，是一笔非常值得的投资。

编程学习 学习日记 实战经验
← 返回列表