# TiDB 7.5 应用实践：个人测试环境下的集群架构设计与部署

前言

完成 PCTP 和 PCSD 的课程学习后，我准备搭建一套 TiDB 7.5 测试集群，把课程中涉及的组件架构、集群部署、监控和故障处理真正跑一遍。

这次实践使用的是个人测试环境，硬件资源无法与生产环境相比。因此，我没有按照生产系统的容量和性能要求配置服务器，而是把重点放在两个方面：

一是尽可能保留 TiDB 的核心分布式结构，包括多个 PD、多个 TiKV 和多个 TiDB Server；二是让环境能够支持后续的节点停止、扩缩容、数据分布观察和简单故障测试。

如果只是为了快速启动 TiDB，使用 TiUP Playground 在一台服务器上就可以运行一套完整环境。但所有组件都集中在同一台主机上，只能验证基本功能，很难观察节点之间的关系，也无法有效模拟主机级故障。

因此，这次我最终采用了 3 台虚拟机混合部署的方式。在资源有限的情况下，把 TiDB Server、PD 和 TiKV 分布到不同虚拟机上，同时集中部署一套监控组件。

一、先确定这套测试集群要解决什么问题

个人实验环境最容易出现的问题，是一开始就把所有组件都装上，却没有想清楚这套环境到底准备验证什么。

我的目标不是模拟生产系统的真实业务量，而是建立一套可以长期保留、反复操作的 TiDB 学习环境，主要用于以下几类实验：

• 熟悉 TiDB Server、PD、TiKV 之间的关系；
• 使用 TiUP 管理集群生命周期；
• 观察 Region、Leader 和副本分布；
• 测试 TiDB Server、PD 或 TiKV 节点停止后的集群状态；
• 练习节点扩容、缩容和配置变更；
• 使用 TiDB Dashboard、Prometheus 和 Grafana 查看监控指标；
• 为后续 SQL、数据迁移和备份恢复测试提供基础环境。

确定目标以后，拓扑设计就比较清楚了。

TiDB Server 本身是无状态 SQL 层，可以部署多个实例，并通过负载均衡组件向应用提供统一入口。PD 保存集群元信息和数据分布状态，负责调度，并为分布式事务提供时间戳服务；官方架构文档建议部署奇数个 PD 节点。TiKV 负责保存实际业务数据，Region 是数据存储和调度的基本单位。

基于这些特点，我没有选择“单机全部署”，而是设计了一套 3 节点混合拓扑。

二、测试环境拓扑设计

1. 虚拟机规划

本次示例使用 3 台 Linux 虚拟机：

这套配置只是个人实验规格，并不是生产环境建议配置。如果物理机内存比较充足，可以为每台虚拟机增加到 16 GB；如果资源紧张，也可以适当降低，但 TiKV 与监控组件同时运行时，内存过小容易产生明显的资源竞争。

三台虚拟机分别部署一个 PD 和一个 TiKV，主要是为了保留以下结构：

• 3 个 PD 组成奇数节点的 PD 集群；
• 3 个 TiKV 承载默认多副本数据；
• 2 个 TiDB Server 用于观察无状态 SQL 层和多入口访问；
• 监控组件集中在第一台虚拟机，减少资源占用。

TiDB Server 没有部署在第三台虚拟机上，是为了在有限资源中给 TiKV 留出更多内存。对测试环境来说，两个 TiDB Server 已经足够验证多实例访问、连接切换和负载均衡。

2. 为什么不用单节点部署

单节点部署的优点是简单，占用资源少，适合快速验证 SQL 和基本功能。

但如果所有 TiDB、PD 和 TiKV 组件都运行在同一台虚拟机上，停止这台主机就等于整个集群停止。即使在同一台主机上启动多个 PD 或 TiKV 实例，也只能模拟进程故障，无法模拟主机故障。

三节点混合部署虽然仍然不是标准生产拓扑，但至少可以观察：

• 某个 PD 停止后，剩余 PD 如何重新选举；
• 某个 TiKV 停止后，Region 和副本状态如何变化；
• 某个 TiDB Server 停止后，其他 SQL 节点是否仍可访问；
• 节点恢复后，集群如何重新同步和调度。

需要注意，如果这 3 台虚拟机最终都运行在同一台物理服务器上，那么物理服务器、宿主机存储和虚拟交换机仍然是共同故障点。这套环境可以验证 TiDB 组件层面的行为，但不能证明具备真正的主机级或机房级高可用能力。

3. 为什么暂时不部署 TiFlash

TiFlash 是 TiKV 的列存扩展，主要用于分析型查询。它可以在同一 TiDB 集群内保存列存副本，为 HTAP 场景提供不同于 TiKV 行存的查询路径。

但 TiFlash 对 CPU、内存和磁盘有额外要求。个人测试环境只有 3 台配置有限的虚拟机，如果一开始就加入 TiFlash，容易让实验重点从集群架构变成资源不足。

因此，我把 TiFlash 作为后续扩展项：

• 第一阶段先完成 TiDB、PD、TiKV 和监控组件部署；
• 第二阶段熟悉基础运维和故障测试；
• 第三阶段再增加一台虚拟机部署 TiFlash，单独验证列存副本和分析查询。

这样做的好处是每个阶段的目标比较明确。遇到问题时，也更容易判断是基础集群问题，还是 TiFlash 组件和资源配置问题。

三、部署前的环境准备

1. 基础条件

3 台虚拟机应满足以下基础条件：

• 主机名和 IP 地址固定；
• 各节点之间网络互通；
• 时间保持同步；
• TiUP 中控机能够通过 SSH 登录所有节点；
• 安装用户具备免密 sudo 权限，或者部署时使用 root 用户；
• 数据目录具有足够空间；
• 防火墙已放通所需端口，测试环境也可以在确认隔离后暂时关闭防火墙。

在 /etc/hosts 中增加主机解析：

192.168.56.101  tidb-lab01
192.168.56.102  tidb-lab02
192.168.56.103  tidb-lab03

分别检查节点连通性：

ping -c 3 tidb-lab01
ping -c 3 tidb-lab02
ping -c 3 tidb-lab03

检查时间同步状态：

timedatectl

分布式数据库依赖节点之间的稳定通信。个人实验环境不需要追求生产级低延迟，但应避免虚拟机时间明显不同、网络频繁丢包或磁盘空间不足，否则后续出现异常时，很难判断是 TiDB 组件问题还是基础环境问题。

2. 创建部署用户

在 3 台节点上创建 tidb 用户：

useradd -m -s /bin/bash tidb
passwd tidb

根据实际管理方式配置 sudo 权限和 SSH 免密登录。

在 TiUP 中控机上生成密钥：

ssh-keygen -t rsa -b 4096

将公钥复制到各节点：

ssh-copy-id tidb@192.168.56.101
ssh-copy-id tidb@192.168.56.102
ssh-copy-id tidb@192.168.56.103

验证登录：

ssh tidb@192.168.56.101 hostname
ssh tidb@192.168.56.102 hostname
ssh tidb@192.168.56.103 hostname

四、安装 TiUP 并准备拓扑文件

1. 安装 TiUP

TiUP 是 TiDB 生态的组件和包管理工具，TiUP Cluster 用于集群部署、扩缩容、升级和日常管理。官方文档提供的安装命令如下：

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

加载环境变量：

source ~/.bash_profile

检查版本：

tiup --version

安装并更新 TiUP Cluster：

tiup install cluster
tiup update --self
tiup update cluster

查看 TiDB 可用版本：

tiup list tidb

这里需要区分两个版本：

• TiUP 和 TiUP Cluster 是集群管理工具版本；
• TiDB 7.5.x 是即将部署的数据库组件版本。

更新 TiUP 不等于升级 TiDB 集群，部署时仍需在命令中明确指定目标 TiDB 版本。

2. 编写拓扑文件

创建拓扑文件：

mkdir -p ~/tidb75
cd ~/tidb75
vi topology.yaml

示例内容如下：

global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"

monitored:
  node_exporter_port: 9100
  blackbox_exporter_port: 9115

server_configs:
  tidb:
    log.slow-threshold: 300

tidb_servers:
  - host: 192.168.56.101
    port: 4000
    status_port: 10080

  - host: 192.168.56.102
    port: 4000
    status_port: 10080

pd_servers:
  - host: 192.168.56.101
    client_port: 2379
    peer_port: 2380

  - host: 192.168.56.102
    client_port: 2379
    peer_port: 2380

  - host: 192.168.56.103
    client_port: 2379
    peer_port: 2380

tikv_servers:
  - host: 192.168.56.101
    port: 20160
    status_port: 20180

  - host: 192.168.56.102
    port: 20160
    status_port: 20180

  - host: 192.168.56.103
    port: 20160
    status_port: 20180

monitoring_servers:
  - host: 192.168.56.101
    port: 9090

grafana_servers:
  - host: 192.168.56.101
    port: 3000

alertmanager_servers:
  - host: 192.168.56.101
    web_port: 9093
    cluster_port: 9094

TiUP Cluster 的部署命令需要指定集群名称、TiDB 版本和拓扑文件，基本格式为：

tiup cluster deploy <cluster-name> <version> <topology.yaml>

这是整个部署过程中最关键的输入。TiUP 会根据拓扑文件确定各组件运行在哪些节点、使用哪些端口，以及程序和数据保存在哪些目录。

3. 拓扑设计中的几个考虑

这个拓扑中，所有节点使用相同的部署目录和数据目录：

/tidb-deploy
/tidb-data

部署目录主要保存程序、配置和日志，数据目录用于保存 TiKV、PD 等组件数据。

如果服务器有独立数据盘，更合理的做法是将 /tidb-data 挂载到单独磁盘。即使是个人实验环境，也不建议把所有数据长期放在容量很小的系统根分区中。

拓扑中设置了：

log.slow-threshold: 300

表示将慢查询阈值设置为 300 毫秒，便于后续测试慢查询和 SQL 诊断。这个值仅用于实验观察，不应直接作为生产环境统一标准。

五、执行环境检查和集群部署

1. 执行部署前检查

在正式部署前运行：

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

TiUP 会检查目标节点的操作系统、SSH、端口、目录和部分系统配置。

如果需要让 TiUP 自动修复部分可处理项目，可以执行：

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

执行 --apply 前应先查看检查结果。即使在实验环境中，也不建议看到报错后直接全部自动修改，而不确认具体变更内容。

2. 部署 TiDB 7.5

本文以 v7.5.0 为示例版本，集群名称为 tidb75-lab：

tiup cluster deploy tidb75-lab v7.5.0 topology.yaml \
  --user root -p

部署过程中，TiUP 会显示即将安装的组件、节点和目录。确认拓扑无误后再继续。

部署完成后查看集群信息：

tiup cluster display tidb75-lab

此时组件已经安装并生成配置，但集群尚未启动。

3. 启动集群

初始化并启动集群：

tiup cluster start tidb75-lab --init

再次查看状态：

tiup cluster display tidb75-lab

正常情况下，应能看到 TiDB、PD、TiKV、Prometheus、Grafana、Alertmanager 和 Node Exporter 等组件处于 Up 状态。

如果某个组件没有正常启动，可以先查看对应日志：

tiup cluster logs tidb75-lab --node 192.168.56.101:4000

也可以登录目标节点，检查 /tidb-deploy 下相应组件的日志目录。

六、集群部署后的基础验证

1. 连接数据库

使用 MySQL 客户端连接任意一个 TiDB Server：

mysql -h 192.168.56.101 -P 4000 -u root -p

查看版本：

SELECT VERSION();

查看当前连接的 TiDB Server：

SELECT @@hostname;

切换到第二个 TiDB Server：

mysql -h 192.168.56.102 -P 4000 -u root -p

再次执行：

SELECT @@hostname;

两个 TiDB Server 都可以访问同一套数据，因为 TiDB Server 本身不保存业务数据，实际数据存放在 TiKV 中。

2. 创建测试数据

CREATE DATABASE labdb;

USE labdb;

CREATE TABLE patient_visit (
    id          BIGINT PRIMARY KEY,
    patient_no  VARCHAR(32) NOT NULL,
    visit_type  VARCHAR(16) NOT NULL,
    visit_time  DATETIME NOT NULL,
    department  VARCHAR(64),
    status      VARCHAR(16)
);

INSERT INTO patient_visit
VALUES
(1, 'P000001', 'OUTPATIENT', NOW(), 'Internal Medicine', 'FINISHED'),
(2, 'P000002', 'INPATIENT',  NOW(), 'Surgery', 'ACTIVE');

SELECT * FROM patient_visit;

然后分别连接两个 TiDB Server 查询：

SELECT * FROM labdb.patient_visit;

如果两个入口得到相同结果，说明 SQL 层可以通过不同 TiDB Server 访问同一套 TiKV 数据。

3. 查看集群节点

在数据库中查看集群信息：

SELECT
    TYPE,
    INSTANCE,
    STATUS_ADDRESS,
    VERSION,
    GIT_HASH
FROM INFORMATION_SCHEMA.CLUSTER_INFO
ORDER BY TYPE, INSTANCE;

该查询可以帮助确认 TiDB、PD 和 TiKV 实例是否全部注册到集群中，也可以用于核对各节点版本是否一致。

七、监控架构验证

使用 TiUP 部署集群时，可以同时部署 Prometheus 和 Grafana。Grafana 中包含 Overview、TiDB、PD、TiKV 和 Node Exporter 等监控面板，可以观察组件状态和主机资源。

本次拓扑中，Grafana 地址为：

http://192.168.56.101:3000

TiDB Dashboard 通常通过 PD 的 Dashboard 入口访问。Dashboard 可以查看 TiDB、TiKV、PD 等组件及其所在主机的运行状态，也可以用于观察慢查询、SQL 分析和部分集群诊断信息。

部署完成后，我重点检查以下内容：

• TiDB、PD、TiKV 实例是否全部在线；
• 3 个 PD 中当前 Leader 位于哪个节点；
• 3 个 TiKV 的存储容量和资源使用是否正常；
• Region 和 Leader 是否分布到不同 TiKV；
• 是否存在持续增长的错误日志；
• 主机 CPU、内存和磁盘使用是否超出实验环境承载能力。

个人测试环境的监控数据不会像生产系统那样丰富，但监控组件仍然有价值。它可以帮助理解一个组件停止以后，集群指标和告警会发生什么变化。

八、验证拓扑设计是否达到预期

1. 停止一个 TiDB Server

先保持客户端连接到第二个 TiDB Server，然后停止第一个 TiDB 实例：

tiup cluster stop tidb75-lab \
  --node 192.168.56.101:4000

检查集群状态：

tiup cluster display tidb75-lab

再连接仍然在线的 TiDB Server：

mysql -h 192.168.56.102 -P 4000 -u root -p

如果第二个入口仍然可以查询数据，说明 TiDB Server 的多实例结构已经生效。

不过，这并不代表应用已经具备自动切换能力。当前客户端直接连接具体 TiDB Server IP，当该节点停止后，客户端仍需要改连另一个地址。

实际应用通常还需要负载均衡或数据库代理。TiDB 可以配合 TiProxy、LVS、HAProxy、ProxySQL 或 F5 等组件提供统一入口。TiProxy 位于客户端和 TiDB Server 之间，可提供服务发现、负载均衡、连接迁移和故障转移等能力。

个人实验环境可以在后续增加一个 TiProxy 节点，进一步测试统一访问地址和 TiDB Server 切换。

恢复 TiDB Server：

tiup cluster start tidb75-lab \
  --node 192.168.56.101:4000

2. 停止一个 PD 节点

查看当前 PD 状态后，选择一个节点停止：

tiup cluster stop tidb75-lab \
  --node 192.168.56.102:2379

观察：

tiup cluster display tidb75-lab

同时继续执行简单查询，确认数据库是否仍可访问。

由于本次部署了 3 个 PD，停止一个节点后仍保留多数派，PD 集群可以继续提供服务。如果只部署两个 PD，停止一个节点后就无法形成多数派，这也是 PD 通常需要采用奇数节点部署的原因。

恢复节点：

tiup cluster start tidb75-lab \
  --node 192.168.56.102:2379

3. 停止一个 TiKV 节点

在没有重要数据的测试环境中，可以进一步停止一个 TiKV：

tiup cluster stop tidb75-lab \
  --node 192.168.56.103:20160

停止后观察：

• SQL 查询是否仍能执行；
• Dashboard 中 Store 状态如何变化；
• Region 副本是否出现异常；
• 是否开始执行副本补偿或调度；
• 节点恢复后是否重新加入集群。

恢复 TiKV：

tiup cluster start tidb75-lab \
  --node 192.168.56.103:20160

需要注意，3 个 TiKV、3 副本的实验拓扑只能承受有限故障。如果连续停止多个 TiKV，使某些 Region 无法形成 Raft 多数派，对应数据就可能暂时无法读写。

多副本提高了节点故障下的数据可用性，但并不替代备份。如果执行错误删除或更新，错误同样会复制到其他副本。

九、这套个人测试拓扑的局限

这套三节点混合部署用来学习和做实验还行，但直接当成生产架构肯定是不够的。

几个关键组件都挤在同一台虚拟机上，资源竞争比较明显。第一台机器同时跑 TiDB、PD、TiKV 和监控组件，CPU 或磁盘压力一大，各组件之间互相影响就很突出。

三台虚拟机其实是部署在同一台物理宿主机上的，而且用的是本地存储。所以宿主机和底层存储仍然存在单点风险，一出问题三台机器都会受牵连。

另外我也没配置统一的访问入口。如果停掉当前连接的那台 TiDB Server，客户端不会自动切换到其他节点，只能手动修改连接字符串。

这个环境目前还没有独立的备份存储，也没有部署 TiFlash、TiCDC，更没有做跨机房容灾和真实业务并发压测。这些功能都得后面再逐步加上。

目前这套拓扑主要用来帮我熟悉 TiDB 核心组件的协作、练习 TiUP Cluster 操作、做一些基本的集群运维操作、观察节点状态变化、验证 SQL 和 MySQL 协议兼容性，也为后续的迁移、备份和故障测试提前准备环境。

十、后续实践计划

基础集群部署完成后，我准备继续围绕这套环境进行扩展。

第一步是增加 TiProxy，为两个 TiDB Server 提供统一访问入口，测试节点停止、滚动重启和连接切换。

第二步是增加 TiFlash 节点，为测试表创建 TiFlash 副本，对比 TiKV 行存与 TiFlash 列存的执行计划和查询方式。

第三步是部署备份存储，使用 BR 完成全量备份、数据删除、集群恢复和结果校验。备份验证的重点不会只放在命令是否成功，而是恢复流程是否完整、数据是否一致以及恢复需要多长时间。

第四步是准备一套 MySQL 测试数据，通过数据迁移工具导入 TiDB，重点检查表结构、字符集、数据类型、SQL 行为和应用连接兼容性。

最后再尝试扩容一个 TiKV 节点，观察 Region 和 Leader 如何重新分布，并比较扩容前后的磁盘容量和调度情况。

结语

这次搭建 TiDB 7.5 测试集群，真正花时间思考的并不是安装命令，而是怎样在有限的个人环境中保留一套有学习价值的分布式架构。

单机部署更快，但三节点混合部署能够看到 PD 多数派、TiKV 副本、TiDB 无状态计算层以及监控系统之间的关系。虽然这套环境距离生产架构还有明显差距，但已经足以支持后续的故障模拟、扩缩容、备份恢复和兼容性测试。

对我来说，部署完成并不代表实验结束。只有真正停止过节点、看过监控变化、执行过恢复，并弄清楚每个组件在异常情况下的行为，这套测试环境才算发挥了作用。