猿创征文｜国产数据库之TiDB详解和安装使用

前言

从上章可以看出，我们国产数据库现在已经走到了一个时代的十字路口，我相信在不久的将来我们国产数据库也能和国外的数据库平起平坐。

接下来我们就讲一讲排行榜第一的TiDB数据库。

1、TiDB简介

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

五大核心特性

• 一键水平扩容或者缩容

  得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

• 金融级高可用

  数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

• 实时 HTAP

  提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

• 云原生的分布式数据库

  专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

• 兼容 MySQL 5.7 协议和 MySQL 生态

  兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

四大核心应用场景

• 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

  众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。

• 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

  随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

• Real-time HTAP 场景

  随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

• 数据汇聚、二次加工处理的场景

  当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

2、TiDB架构

• TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

• PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

• 存储节点

  • TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
  • TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

3、TiDB的安装使用

3.1、部署本地测试集群

• 适用场景：利用本地 macOS 或者单机 Linux 环境快速部署 TiDB 测试集群，体验 TiDB 集群的基本架构，以及 TiDB、TiKV、PD、监控等基础组件的运行。

TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 TiDB 实例、3 个 TiKV 实例、3 个 PD 实例和可选的 TiFlash 实例构成。通过 TiUP Playground，可以快速搭建出上述的一套基础测试集群，步骤如下：

1、下载并安装 。

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

安装完成后会提示如下信息：

Successfully set mirror to https://tiup-mirrors.pingcap.com
Detected shell: bash
Shell profile:  /root/.bash_profile
Installed path: /root/.tiup/bin/tiup
===============================================
Have a try:     tiup playground
===============================================

2、声明全局环境变量。

注意
TiUP 安装完成后会提示 Shell profile 文件的绝对路径。在执行以下 source 命令前，需要将 ${your_shell_profile} 修改为 Shell profile 文件的实际位置。

source /root/.bash_profile

3、在当前 session 执行以下命令启动集群。

• 直接执行 tiup playground 命令会运行最新版本的 TiDB 集群，其中 TiDB、TiKV、PD 和 TiFlash 实例各 1 个：

tiup playground

• 也可以指定 TiDB 版本以及各组件实例个数，命令类似于：

tiup playground v6.3.0 --db 2 --pd 3 --kv 3

上述命令会在本地下载并启动某个版本的集群（例如 v6.2.0）。最新版本可以通过执行 tiup list tidb 来查看。运行结果将显示集群的访问方式：

CLUSTER START SUCCESSFULLY, Enjoy it ^-^
To connect TiDB: mysql --comments --host 127.0.0.1 --port 4001 -u root -p (no password)
To connect TiDB: mysql --comments --host 127.0.0.1 --port 4000 -u root -p (no password)
To view the dashboard: http://127.0.0.1:2379/dashboard
PD client endpoints: [127.0.0.1:2379 127.0.0.1:2382 127.0.0.1:2384]
To view the Prometheus: http://127.0.0.1:9090
To view the Grafana: http://127.0.0.1:3000

注意
1、支持 v5.2.0 及以上版本的 TiDB 在 Apple M1 芯片的机器上运行 tiup playground。
2、以这种方式执行的 playground，在结束部署测试后 TiUP 会清理掉原集群数据，重新执行该命令后会得到一个全新的集群。
3、若希望持久化数据，可以执行 TiUP 的 –tag 参数：tiup --tag playground …，详情参考 TiUP 参考手册。

4、新开启一个 session 以访问 TiDB 数据库。

• 使用 TiUP client 连接 TiDB：

tiup client

• 也可使用 MySQL 客户端连接 TiDB：

mysql --host 127.0.0.1 --port 4000 -u root

5、通过 http://127.0.0.1:9090 访问 TiDB 的 Prometheus 管理界面。

6、通过 http://127.0.0.1:2379/dashboard 访问 TiDB Dashboard 页面，默认用户名为 root，密码为空。

7、通过 http://127.0.0.1:3000 访问 TiDB 的 Grafana 界面，默认用户名和密码都为 admin。

8、（可选）将数据加载到 TiFlash 进行分析。

9、测试完成之后，可以通过执行以下步骤来清理集群：

• 按下 Control+C 键停掉上述启用的 TiDB 服务。

• 等待服务退出操作完成后，执行以下命令：

tiup clean --all

注意
TiUP Playground 默认监听 127.0.0.1，服务仅本地可访问；若需要使服务可被外部访问，可使用 --host 参数指定监听网卡绑定外部可访问的 IP。

3.2、在单机上模拟部署生产环境集群

• 适用场景：希望用单台 Linux 服务器，体验 TiDB 最小的完整拓扑的集群，并模拟生产环境下的部署步骤。

下面介绍如何参照 TiUP 最小拓扑的一个 YAML 文件部署 TiDB 集群。

准备环境
准备一台部署主机，确保其软件满足需求：

• 推荐安装 CentOS 7.3 及以上版本
• 运行环境可以支持互联网访问，用于下载 TiDB 及相关软件安装包
  最小规模的 TiDB 集群拓扑：

注意
下表中拓扑实例的 IP 为示例 IP。在实际部署时，请替换为实际的 IP。

实例	个数	IP	配置
TiKV	3	10.0.1.1 10.0.1.1 10.0.1.1	避免端口和目录冲突
TiDB	1	10.0.1.1	默认端口 全局目录配置
PD	1	10.0.1.1	默认端口 全局目录配置
TiFlash	1	10.0.1.1	默认端口 全局目录配置
Monitor	1	10.0.1.1	默认端口 全局目录配置

部署主机软件和环境要求：

• 部署需要使用部署主机的 root 用户及密码
• 部署主机关闭防火墙或者开放 TiDB 集群的节点间所需端口
• 目前 TiUP Cluster 支持在 x86_64（AMD64）和 ARM 架构上部署 TiDB 集群
  • 在 AMD64 架构下，建议使用 CentOS 7.3 及以上版本 Linux 操作系统
  • 在 ARM 架构下，建议使用 CentOS 7.6 1810 版本 Linux 操作系统

实施部署

注意
你可以使用 Linux 系统的任一普通用户或 root 用户登录主机，以下步骤以 root 用户为例。

1、下载并安装 TiUP：

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

2、声明全局环境变量：

注意
TiUP 安装完成后会提示对应 Shell profile 文件的绝对路径。在执行以下 source 命令前，需要将 ${your_shell_profile} 修改为 Shell profile 文件的实际位置。

source /root/.bash_profile

3、安装 TiUP 的 cluster 组件：

tiup cluster

4、如果机器已经安装 TiUP cluster，需要更新软件版本：

tiup update --self && tiup update cluster

5、由于模拟多机部署，需要通过 root 用户调大 sshd 服务的连接数限制：

• 修改 /etc/ssh/sshd_config 将 MaxSessions 调至 20。

• 重启 sshd 服务：

service sshd restart

6、创建并启动集群

按下面的配置模板，编辑配置文件，命名为 topo.yaml，其中：

• user: “tidb”：表示通过 tidb 系统用户（部署会自动创建）来做集群的内部管理，默认使用 22 端口通过 ssh 登录目标机器
• replication.enable-placement-rules：设置这个 PD 参数来确保 TiFlash 正常运行
• host：设置为本部署主机的 IP
  配置模板如下：

# # Global variables are applied to all deployments and used as the default value of
# # the deployments if a specific deployment value is missing.
global:
 user: "tidb"
 ssh_port: 22
 deploy_dir: "/tidb-deploy"
 data_dir: "/tidb-data"

# # Monitored variables are applied to all the machines.
monitored:
 node_exporter_port: 9100
 blackbox_exporter_port: 9115

server_configs:
 tidb:
   log.slow-threshold: 300
 tikv:
   readpool.storage.use-unified-pool: false
   readpool.coprocessor.use-unified-pool: true
 pd:
   replication.enable-placement-rules: true
   replication.location-labels: ["host"]
 tiflash:
   logger.level: "info"

pd_servers:
 - host: 10.0.1.1

tidb_servers:
 - host: 10.0.1.1

tikv_servers:
 - host: 10.0.1.1
   port: 20160
   status_port: 20180
   config:
     server.labels: { host: "logic-host-1" }

 - host: 10.0.1.1
   port: 20161
   status_port: 20181
   config:
     server.labels: { host: "logic-host-2" }

 - host: 10.0.1.1
   port: 20162
   status_port: 20182
   config:
     server.labels: { host: "logic-host-3" }

tiflash_servers:
 - host: 10.0.1.1

monitoring_servers:
 - host: 10.0.1.1

grafana_servers:
 - host: 10.0.1.1

7、执行集群部署命令：

tiup cluster deploy <cluster-name> <tidb-version> ./topo.yaml --user root -p

• 参数 表示设置集群名称

• 参数 表示设置集群版本，可以通过 tiup list tidb 命令来查看当前支持部署的 TiDB 版本

• 参数 -p 表示在连接目标机器时使用密码登录

注意
如果主机通过密钥进行 SSH 认证，请使用 -i 参数指定密钥文件路径，-i 与 -p 不可同时使用。

按照引导，输入”y”及 root 密码，来完成部署：

Do you want to continue? [y/N]:  y
Input SSH password:

8、启动集群：

tiup cluster start <cluster-name>

9、访问集群：

• 安装 MySQL 客户端。如果已安装 MySQL 客户端则可跳过这一步骤。

yum -y install mysql

• 访问 TiDB 数据库，密码为空：

mysql -h 10.0.1.1 -P 4000 -u root

• 访问 TiDB 的 Grafana 监控：

  通过 http://{grafana-ip}:3000 访问集群 Grafana 监控页面，默认用户名和密码均为 admin。

• 访问 TiDB 的 Dashboard：

  通过 http://{pd-ip}:2379/dashboard 访问集群 TiDB Dashboard 监控页面，默认用户名为 root，密码为空。

• 执行以下命令确认当前已经部署的集群列表：

tiup cluster list

• 执行以下命令查看集群的拓扑结构和状态：

tiup cluster display <cluster-name>

4、在生产环境部署TiDB

4.1、软硬件环境需求及前置检查

TiUP 是 TiDB 4.0 版本引入的集群运维工具，TiUP cluster 是 TiUP 提供的使用 Golang 编写的集群管理组件，通过 TiUP cluster 组件就可以进行日常的运维工作，包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群，以及管理 TiDB 集群参数。

目前 TiUP 可以支持部署 TiDB、TiFlash、TiDB Binlog、TiCDC 以及监控系统。本文将介绍不同集群拓扑的具体部署步骤。

注意
TiDB、TiUP 及 TiDB Dashboard 默认会收集使用情况信息，并将这些信息分享给 PingCAP 用于改善产品。若要了解所收集的信息详情及如何禁用该行为，请参见遥测。

1、软硬件环境需求
自 v6.1.1 开始，针对不同操作系统和 CPU 架构的组合，TiDB 提供不同级别质量标准的支持。

• 在以下操作系统以及对应的 CPU 架构组合上，TiDB 可满足企业级生产质量的要求，产品特性经过全面且系统化的验证：

操作系统	支持的 CPU 架构
Red Hat Enterprise Linux 8.4 及以上的 8.x 版本 CentOS 8.4 及以上的 8.x 版本	x86_64 ARM 64
Red Hat Enterprise Linux 7.3 及以上的 7.x 版本 CentOS 7.3 及以上的 7.x 版本	x86_64 ARM 64
麒麟欧拉版 V10 SP1/SP2	x86_64 ARM 64
UOS V20	x86_64 ARM 64

注意
根据 CentOS Linux EOL，CentOS 的上游支持已于 2021 年 12 月 31 日终止。

• 在以下操作系统以及对应的 CPU 架构组合上，你可以编译、构建和部署 TiDB，可使用 OLTP 和 OLAP 以及数据工具的基本功能。但是 TiDB 不保障企业级生产质量要求：

操作系统	支持的 CPU 架构
macOS Catalina 及以上的版本	x86_64 ARM 64
Oracle Enterprise Linux 7.3 及以上的 7.x 版本	x86_64
Ubuntu LTS 18.04 及以上的版本	x86_64
Debian 9 (Stretch) 及以上的版本	x86_64
Fedora 35 及以上的版本	x86_64
openSUSE Leap 15.3 以上的版本（不包含 Tumbleweed）	x86_64
SUSE Linux Enterprise Server 15	x86_64

注意
1、TiDB 只支持 Red Hat 兼容内核 (RHCK) 的 Oracle Enterprise Linux，不支持 Oracle Enterprise Linux 提供的 Unbreakable Enterprise Kernel。
2、TiDB 将不再支持 Ubuntu 16.04。强烈建议升级到 Ubuntu 18.04 或更高版本。

• 对于以上两个表格中所列操作系统的 32 位版本，TiDB 在这些 32 位操作系统以及对应的 CPU 架构上不保障可编译、可构建以及可部署，或 TiDB 不主动适配这些 32 位的操作系统。

• 以上未提及的操作系统版本也许可以运行 TiDB，但尚未得到 TiDB 官方支持。

编译和运行 TiDB 所依赖的库

编译和构建 TiDB 所需的依赖库	版本
Golang	1.18.5 及以上版本
Rust	nightly-2022-07-31 及以上版本
GCC	7.x
LLVM	13.0 及以上版本

运行时所需的依赖库：glibc（2.28-151.el8 版本）

软件配置要求
中控机软件配置

软件	版本
sshpass	1.06 及以上
TiUP	1.5.0 及以上

注意
中控机需要部署 TiUP 软件来完成 TiDB 集群运维管理。

目标主机建议配置软件

软件	版本
sshpass	1.06 及以上
numa	2.0.12 及以上
tar	任意

服务器建议配置
TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台或者 ARM 架构的硬件服务器平台。对于开发、测试及生产环境的服务器硬件配置（不包含操作系统 OS 本身的占用）有以下要求和建议：

开发及测试环境

组件	CPU	内存	本地存储	网络	实例数量(最低要求)
TiDB	8 核+	16 GB+	无特殊要求	千兆网卡	1（可与 PD 同机器）
PD	4 核+	8 GB+	SAS, 200 GB+	千兆网卡	1（可与 TiDB 同机器）
TiKV	8 核+	32 GB+	SSD, 200 GB+	千兆网卡	3
TiFlash	32 核+	64 GB+	SSD, 200 GB+	千兆网卡	1
TiCDC	8 核+	16 GB+	SAS, 200 GB+	千兆网卡	1

注意
1、验证测试环境中的 TiDB 和 PD 可以部署在同一台服务器上。
2、如进行性能相关的测试，避免采用低性能存储和网络硬件配置，防止对测试结果的正确性产生干扰。
3、TiKV 的 SSD 盘推荐使用 NVME 接口以保证读写更快。
4、如果仅验证功能，建议使用 TiDB 数据库快速上手指南进行单机功能测试。
5、TiDB 对于磁盘的使用以存放日志为主，因此在测试环境中对于磁盘类型和容量并无特殊要求。

生产环境

组件	CPU	内存	硬盘类型	网络	实例数量(最低要求)
TiDB	16 核+	48 GB+	SAS	万兆网卡（2 块最佳）	2
PD	8 核+	16 GB+	SSD	万兆网卡（2 块最佳）	3
TiKV	16 核+	64 GB+	SSD	万兆网卡（2 块最佳）	3
TiFlash	48 核+	128 GB+	1 or more SSDs	万兆网卡（2 块最佳）	2
TiCDC	16 核+	64 GB+	SSD	万兆网卡（2 块最佳）	2
监控	8 核+	16 GB+	SAS	千兆网卡	1

注意
1、生产环境中的 TiDB 和 PD 可以部署和运行在同一台服务器上，如对性能和可靠性有更高的要求，应尽可能分开部署。
2、生产环境强烈推荐使用更高的配置。
3、TiKV 硬盘大小配置建议 PCI-E SSD 不超过 2 TB，普通 SSD 不超过 1.5 TB。
4、TiFlash 支持多盘部署。
5、TiFlash 数据目录的第一块磁盘推荐用高性能 SSD 来缓冲 TiKV 同步数据的实时写入，该盘性能应不低于 TiKV 所使用的磁盘，比如 PCI-E SSD。并且该磁盘容量建议不小于总容量的 10%，否则它可能成为这个节点的能承载的数据量的瓶颈。而其他磁盘可以根据需求部署多块普通 SSD，当然更好的 PCI-E SSD 硬盘会带来更好的性能。
6、TiFlash 推荐与 TiKV 部署在不同节点，如果条件所限必须将 TiFlash 与 TiKV 部署在相同节点，则需要适当增加 CPU 核数和内存，且尽量将 TiFlash 与 TiKV 部署在不同的磁盘，以免互相干扰。
7、TiFlash 硬盘总容量大致为：整个 TiKV 集群的需同步数据容量 / TiKV 副本数 * TiFlash 副本数。例如整体 TiKV 的规划容量为 1 TB、TiKV 副本数为 3、TiFlash 副本数为 2，则 TiFlash 的推荐总容量为 1024 GB / 3 * 2。用户可以选择同步部分表数据而非全部，具体容量可以根据需要同步的表的数据量具体分析。
8、TiCDC 硬盘配置建议 1 TB+ PCIE-SSD。

网络要求
TiDB 作为开源分布式 NewSQL 数据库，其正常运行需要网络环境提供如下的网络端口配置要求，管理员可根据实际环境中 TiDB 组件部署的方案，在网络侧和主机侧开放相关端口：

组件	默认端口	说明
TiDB	4000	应用及 DBA 工具访问通信端口
TiDB	10080	TiDB 状态信息上报通信端口
TiKV	20160	TiKV 通信端口
TiKV	20180	TiKV 状态信息上报通信端口
PD	2379	提供 TiDB 和 PD 通信端口
PD	2380	PD 集群节点间通信端口
TiFlash	9000	TiFlash TCP 服务端口
TiFlash	8123	TiFlash HTTP 服务端口
TiFlash	3930	TiFlash RAFT 服务和 Coprocessor 服务端口
TiFlash	20170	TiFlash Proxy 服务端口
TiFlash	20292	Prometheus 拉取 TiFlash Proxy metrics 端口
TiFlash	8234	Prometheus 拉取 TiFlash metrics 端口
Pump	8250	Pump 通信端口
Drainer	8249	Drainer 通信端口
CDC	8300	CDC 通信接口
Monitoring	9090	Prometheus 服务通信端口
Monitoring	20120	NgMonitoring 服务通信端口
Node_exporter	9100	TiDB 集群每个节点的系统信息上报通信端口
Blackbox_exporter	9115	Blackbox_exporter 通信端口，用于 TiDB 集群端口监控
Grafana	3000	Web 监控服务对外服务和客户端(浏览器)访问端口
Alertmanager	9093	告警 web 服务端口
Alertmanager	9094	告警通信端口

磁盘空间要求

组件	磁盘空间要求	健康水位使用率
TiDB	日志盘建议最少预留 30 GB	低于 90%
PD	数据盘和日志盘建议最少各预留 20 GB	低于 90%
TiKV	数据盘和日志盘建议最少各预留 100 GB	低于 80%
TiFlash	数据盘建议最少预留 100 GB，日志盘建议最少预留 30 GB	低于 80%
TiUP	中控机：部署一个版本的 TiDB 集群占用不超过 1 GB 空间，部署多个版本集群所占用的空间会相应增加 部署服务器（实际运行 TiDB 各组件的机器）：TiFlash 占用约 700 MB 空间，其他组件（PD、TiDB、TiKV 等）各占用约 200 MB 空间。同时，部署过程会占用小于 1 MB 临时空间（/tmp）存放临时文件	不涉及
Ngmonitoring	Conprof：3 x 1 GB x 组件数量（表示每个组件每天占用约 1 GB，总共 3 天） + 20 GB 预留空间Top SQL：30 x 50 MB x 组件数量（每个组件每天占用约 50 MB，总共 30 天） Top SQL 和 Conprof 共享预留空间	不涉及

客户端 Web 浏览器要求
TiDB 提供了基于 Grafana 的技术平台，对数据库集群的各项指标进行可视化展现。采用支持 Javascript 的微软 IE、Google Chrome、Mozilla Firefox 的较新版本即可访问监控入口。

4.2、环境与系统配置检查

在 TiKV 部署目标机器上添加数据盘 EXT4 文件系统挂载参数

生产环境部署，建议使用 EXT4 类型文件系统的 NVME 类型的 SSD 磁盘存储 TiKV 数据文件。这个配置方案为最佳实施方案，其可靠性、安全性、稳定性已经在大量线上场景中得到证实。

使用 root 用户登录目标机器，将部署目标机器数据盘格式化成 ext4 文件系统，挂载时添加 nodelalloc 和 noatime 挂载参数。nodelalloc 是必选参数，否则 TiUP 安装时检测无法通过；noatime 是可选建议参数。

注意
如果你的数据盘已经格式化成 ext4 并挂载了磁盘，可先执行 umount /dev/nvme0n1p1 命令卸载，从编辑 /etc/fstab 文件步骤开始执行，添加挂载参数重新挂载即可。

以 /dev/nvme0n1 数据盘为例，具体操作步骤如下：

1、查看数据盘。

fdisk -l
Disk /dev/nvme0n1: 1000 GB

2、创建分区。

parted -s -a optimal /dev/nvme0n1 mklabel gpt -- mkpart primary ext4 1 -1

注意
使用 lsblk 命令查看分区的设备号：对于 nvme 磁盘，生成的分区设备号一般为 nvme0n1p1；对于普通磁盘（例如 /dev/sdb），生成的分区设备号一般为 sdb1。

3、格式化文件系统。

mkfs.ext4 /dev/nvme0n1p1

4、查看数据盘分区 UUID。

本例中 nvme0n1p1 的 UUID 为 c51eb23b-195c-4061-92a9-3fad812cc12f。

lsblk -f

NAME    FSTYPE LABEL UUID                                 MOUNTPOINT
sda
├─sda1  ext4         237b634b-a565-477b-8371-6dff0c41f5ab /boot
├─sda2  swap         f414c5c0-f823-4bb1-8fdf-e531173a72ed
└─sda3  ext4         547909c1-398d-4696-94c6-03e43e317b60 /
sr0
nvme0n1
└─nvme0n1p1 ext4         c51eb23b-195c-4061-92a9-3fad812cc12f

5、编辑 /etc/fstab 文件，添加 nodelalloc 挂载参数。

vi /etc/fstab
UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatime 0 2

6、挂载数据盘。

mkdir /data1 && \
mount -a

7、执行以下命令，如果文件系统为 ext4，并且挂载参数中包含 nodelalloc，则表示已生效。

mount -t ext4
/dev/nvme0n1p1 on /data1 type ext4 (rw,noatime,nodelalloc,data=ordered)

检测及关闭系统 swap
TiDB 运行需要有足够的内存。如果内存不足，不建议使用 swap 作为内存不足的缓冲，因为这会降低性能。建议永久关闭系统 swap。

要永久关闭 swap，可执行以如下命令:

echo "vm.swappiness = 0">> /etc/sysctl.conf
swapoff -a && swapon -a
sysctl -p

注意
1、一起执行 swapoff -a 和 swapon -a 命令是为了刷新 swap，将 swap 里的数据转储回内存，并清空 swap 里的数据。不可省略 swappiness 设置而只执行 swapoff -a；否则，重启后 swap 会再次自动打开，使得操作失效。
2、执行 sysctl -p 命令是为了在不重启的情况下使配置生效。

检测及关闭目标部署机器的防火墙

本段介绍如何关闭目标主机防火墙配置，因为在 TiDB 集群中，需要将节点间的访问端口打通才可以保证读写请求、数据心跳等信息的正常的传输。在普遍线上场景中，数据库到业务服务和数据库节点的网络联通都是在安全域内完成数据交互。如果没有特殊安全的要求，建议将目标节点的防火墙进行关闭。否则建议按照端口使用规则，将端口信息配置到防火墙服务的白名单中。

1、检查防火墙状态（以 CentOS Linux release 7.7.1908 (Core) 为例）

sudo firewall-cmd --state
sudo systemctl status firewalld.service

2、关闭防火墙服务

sudo systemctl stop firewalld.service

3、关闭防火墙自动启动服务

sudo systemctl disable firewalld.service

4、检查防火墙状态

sudo systemctl status firewalld.service

检测及安装 NTP 服务

TiDB 是一套分布式数据库系统，需要节点间保证时间的同步，从而确保 ACID 模型的事务线性一致性。目前解决授时的普遍方案是采用 NTP 服务，可以通过互联网中的 pool.ntp.org 授时服务来保证节点的时间同步，也可以使用离线环境自己搭建的 NTP 服务来解决授时。

采用如下步骤检查是否安装 NTP 服务以及与 NTP 服务器正常同步：

1、执行以下命令，如果输出 running 表示 NTP 服务正在运行：

sudo systemctl status ntpd.service

ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled)
Active: active (running) since 一 2022-10-04 13:13:19 CST; 3s ago

• 若返回报错信息 Unit ntpd.service could not be found.，请尝试执行以下命令，以查看与 NTP 进行时钟同步所使用的系统配置是 chronyd 还是 ntpd：

sudo systemctl status chronyd.service

chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-10-05 09:55:29 EDT; 3 days ago

若发现系统既没有配置 chronyd 也没有配置 ntpd ，则表示系统尚未安装任一服务。此时，应先安装其中一个服务，并保证它可以自动启动，默认使用 ntpd。

如果你使用的系统配置是 chronyd，请直接执行步骤 3。

2、执行 ntpstat 命令检测是否与 NTP 服务器同步：

注意
Ubuntu 系统需安装 ntpstat 软件包。

ntpstat

• 如果输出 synchronised to NTP server，表示正在与 NTP 服务器正常同步：

synchronised to NTP server (85.199.214.101) at stratum 2
time correct to within 91 ms
polling server every 1024 s

• 以下情况表示 NTP 服务未正常同步：

unsynchronised

• 以下情况表示 NTP 服务未正常运行：

Unable to talk to NTP daemon. Is it running?

3、执行 chronyc tracking 命令查看 Chrony 服务是否与 NTP 服务器同步。

注意
该操作仅适用于使用 Chrony 的系统，不适用于使用 NTPd 的系统。

chronyc tracking

• 如果该命令返回结果为 Leap status : Normal，则代表同步过程正常。

Reference ID    : 5EC69F0A (ntp1.time.nl)
Stratum         : 2
Ref time (UTC)  : Thu May 20 15:19:08 2021
System time     : 0.000022151 seconds slow of NTP time
Last offset     : -0.000041040 seconds
RMS offset      : 0.000053422 seconds
Frequency       : 2.286 ppm slow
Residual freq   : -0.000 ppm
Skew            : 0.012 ppm
Root delay      : 0.012706812 seconds
Root dispersion : 0.000430042 seconds
Update interval : 1029.8 seconds
Leap status     : Normal

• 如果该命令返回结果如下，则表示同步过程出错：

Leap status    : Not synchronised

• 如果该命令返回结果如下，则表示 Chrony 服务未正常运行：

506 Cannot talk to daemon

如果要使 NTP 服务尽快开始同步，执行以下命令。可以将 pool.ntp.org 替换为你的 NTP 服务器：

sudo systemctl stop ntpd.service && \
sudo ntpdate pool.ntp.org && \
sudo systemctl start ntpd.service

如果要在 CentOS 7 系统上手动安装 NTP 服务，可执行以下命令：

sudo yum install ntp ntpdate && \
sudo systemctl start ntpd.service && \
sudo systemctl enable ntpd.service

4.3、在中控机上部署 TiUP 组件

在中控机上部署 TiUP 组件有两种方式：在线部署和离线部署。

在线部署
以普通用户身份登录中控机。以 tidb 用户为例，后续安装 TiUP 及集群管理操作均通过该用户完成：

1、执行如下命令安装 TiUP 工具：

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

2、按如下步骤设置 TiUP 环境变量：

• 重新声明全局环境变量：

source .bash_profile

• 确认 TiUP 工具是否安装：

which tiup

3、安装 TiUP cluster 组件：

tiup cluster

4、如果已经安装，则更新 TiUP cluster 组件至最新版本：

tiup update --self && tiup update cluster

预期输出 “Update successfully!” 字样。

5、验证当前 TiUP cluster 版本信息。执行如下命令查看 TiUP cluster 组件版本：

tiup --binary cluster

离线部署
离线部署 TiUP 组件的操作步骤如下。

准备 TiUP 离线组件包
方式一：在官方下载页面选择对应版本的 TiDB server 离线镜像包（包含 TiUP 离线组件包）。

方式二：使用 tiup mirror clone 命令手动打包离线组件包。步骤如下：

1、在在线环境中安装 TiUP 包管理器工具

• 执行如下命令安装 TiUP 工具：

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

• 重新声明全局环境变量：

source .bash_profile

• 确认 TiUP 工具是否安装：

which tiup

2、使用 TiUP 制作离线镜像

• 在一台和外网相通的机器上拉取需要的组件：

tiup mirror clone tidb-community-server-${version}-linux-amd64 ${version} --os=linux --arch=amd64

该命令会在当前目录下创建一个名叫 tidb-community-server-${version}-linux-amd64 的目录，里面包含 TiUP 管理的组件包。

• 通过 tar 命令将该组件包打包然后发送到隔离环境的中控机：

tar czvf tidb-community-server-${version}-linux-amd64.tar.gz tidb-community-server-${version}-linux-amd64

此时，tidb-community-server-${version}-linux-amd64.tar.gz 就是一个独立的离线环境包。

3、自定义制作的离线镜像，或调整已有离线镜像中的内容

如果从官网下载的离线镜像不满足你的具体需求，或者希望对已有的离线镜像内容进行调整，例如增加某个组件的新版本等，可以采取以下步骤进行操作：

• 在制作离线镜像时，可通过参数指定具体的组件和版本等信息，获得不完整的离线镜像。例如，要制作一个只包括 v1.10.0 版本 TiUP 和 TiUP Cluster 的离线镜像，可执行如下命令：

tiup mirror clone tiup-custom-mirror-v1.10.0 --tiup v1.10.0 --cluster v1.10.0

如果只需要某一特定平台的组件，也可以通过 --os 和 --arch 参数来指定。

• 参考上文“使用 TiUP 制作离线镜像”第 2 步的方式，将此不完整的离线镜像传输到隔离环境的中控机。

• 在隔离环境的中控机上，查看当前使用的离线镜像路径。较新版本的 TiUP 可以直接通过命令获取当前的镜像地址：

tiup mirror show

以上命令如果提示 show 命令不存在，可能当前使用的是较老版本的 TiUP。此时可以通过查看 $HOME/.tiup/tiup.toml 获得正在使用的镜像地址。将此镜像地址记录下来，后续步骤中将以变量 ${base_mirror} 指代此镜像地址。

• 将不完整的离线镜像合并到已有的离线镜像中：

  首先将当前离线镜像中的 keys 目录复制到 $HOME/.tiup 目录中：

cp -r ${base_mirror}/keys $HOME/.tiup/

然后使用 TiUP 命令将不完整的离线镜像合并到当前使用的镜像中：

tiup mirror merge tiup-custom-mirror-v1.10.0

• 上述步骤完成后，通过 tiup list 命令检查执行结果。在本文例子中，使用 tiup list tiup 和 tiup list cluster 均应能看到对应组件的 v1.10.0 版本出现在结果中。

部署离线环境 TiUP 组件

将离线包发送到目标集群的中控机后，执行以下命令安装 TiUP 组件：

tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz && \
sh tidb-community-server-${version}-linux-amd64/local_install.sh && \
source /home/tidb/.bash_profile

local_install.sh 脚本会自动执行 tiup mirror set tidb-community-server-$version-linux-amd64命令将当前镜像地址设置为tidb-community-server-${version}-linux-amd64。

若需将 server 和 toolkit 两个离线镜像合并，执行以下命令合并离线组件到 server 目录下。

tar xf tidb-community-toolkit-${version}-linux-amd64.tar.gz
ls -ld tidb-community-server-${version}-linux-amd64 tidb-community-toolkit-${version}-linux-amd64
cd tidb-community-server-${version}-linux-amd64/
cp -rp keys ~/.tiup/
tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64

若需将镜像切换到其他目录，可以通过手动执行 tiup mirror set 进行切换。如果需要切换到在线环境，可执行 tiup mirror set https://tiup-mirrors.pingcap.com。

4.4、初始化集群拓扑文件

执行如下命令，生成集群初始化配置文件：

tiup cluster template > topology.yaml

针对两种常用的部署场景，也可以通过以下命令生成建议的拓扑模板：

• 混合部署场景：单台机器部署多个实例，详情参见混合部署拓扑架构 。

tiup cluster template --full > topology.yaml

• 跨机房部署场景：跨机房部署 TiDB 集群，详情参见跨机房部署拓扑架构。

tiup cluster template --multi-dc > topology.yaml

执行 vi topology.yaml，查看配置文件的内容：

global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"
server_configs: {}
pd_servers:
  - host: 10.0.1.4
  - host: 10.0.1.5
  - host: 10.0.1.6
tidb_servers:
  - host: 10.0.1.7
  - host: 10.0.1.8
  - host: 10.0.1.9
tikv_servers:
  - host: 10.0.1.1
  - host: 10.0.1.2
  - host: 10.0.1.3
monitoring_servers:
  - host: 10.0.1.4
grafana_servers:
  - host: 10.0.1.4
alertmanager_servers:
  - host: 10.0.1.4

下表列出了常用的 7 种场景，请根据链接中的拓扑说明以及配置文件模板配置topology.yaml。如果有其他组合场景的需求，请根据多个模板自行调整。

场景	配置任务	配置文件模板	拓扑说明
OLTP 业务	部署最小拓扑架构	简单最小配置模板 详细最小配置模板	最小集群拓扑，包括 tidb-server、tikv-server、pd-server。
HTAP 业务	部署 TiFlash 拓扑架构	简单 TiFlash 配置模版 详细 TiFlash 配置模版	在最小拓扑的基础上部署 TiFlash。TiFlash 是列式存储引擎，已经逐步成为集群拓扑的标配。
使用 TiCDC 进行增量同步	部署 TiCDC 拓扑架构	简单 TiCDC 配置模板 详细 TiCDC 配置模板	在最小拓扑的基础上部署 TiCDC。TiCDC 支持多种下游 (TiDB/MySQL/MQ)。
使用 TiDB Binlog 进行增量同步	部署 TiDB Binlog 拓扑架构	简单 TiDB Binlog 配置模板（下游为 MySQL）简单 TiDB Binlog 配置模板（下游为 file 详细 TiDB Binlog 配置模板	在最小拓扑的基础上部署 TiDB Binlog。
使用 Spark 的 OLAP 业务	部署 TiSpark 拓扑架构	简单 TiSpark 配置模板 详细 TiSpark 配置模板	在最小拓扑的基础上部署 TiSpark 组件。TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。TiUP cluster 组件对 TiSpark 的支持目前为实验特性。
单台机器，多个实例	混合部署拓扑架构	简单混部配置模板 详细混部配置模板	也适用于单机多实例需要额外增加目录、端口、资源配比、label 等配置的场景。
跨机房部署 TiDB 集群	跨机房部署拓扑架构	跨机房配置模板	以典型的两地三中心架构为例，介绍跨机房部署架构，以及需要注意的关键设置。

注意
1、对于需要全局生效的参数，请在配置文件中 server_configs 的对应组件下配置。
2、对于需要某个节点生效的参数，请在具体节点的 config 中配置。
3、配置的层次结构使用 . 表示。如：log.slow-threshold。更多格式参考 TiUP 配置参数模版。
4、如果需要指定在目标机创建的用户组名，可以参考这个例子。

更多参数说明，请参考：

TiDB config.toml.example
TiKV config.toml.example
PD config.toml.example
TiFlash config.toml.example

4.5、执行部署命令

注意
通过 TiUP 进行集群部署可以使用密钥或者交互密码方式来进行安全认证：
1、如果是密钥方式，可以通过 -i 或者 --identity_file 来指定密钥的路径。
2、如果是密码方式，可以通过 -p 进入密码交互窗口。
3、如果已经配置免密登录目标机，则不需填写认证。
一般情况下 TiUP 会在目标机器上创建 topology.yaml 中约定的用户和组，以下情况例外：
1、topology.yaml 中设置的用户名在目标机器上已存在。
2、在命令行上使用了参数 --skip-create-user 明确指定跳过创建用户的步骤。

执行部署命令前，先使用 check 及 check --apply 命令检查和自动修复集群存在的潜在风险：

1、检查集群存在的潜在风险：

tiup cluster check ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

2、自动修复集群存在的潜在风险：

tiup cluster check ./topology.yaml --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa]

3、部署 TiDB 集群：

tiup cluster deploy tidb-test v6.3.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

以上部署示例中：

• tidb-test 为部署的集群名称。
• v6.3.0 为部署的集群版本，可以通过执行 tiup list tidb 来查看 TiUP 支持的最新可用版本。
• 初始化配置文件为 topology.yaml。
• –user root 表示通过 root 用户登录到目标主机完成集群部署，该用户需要有 ssh 到目标机器的权限，并且在目标机器有 sudo 权限。也可以用其他有 ssh 和 sudo 权限的用户完成部署。
• [-i] 及 [-p] 为可选项，如果已经配置免密登录目标机，则不需填写。否则选择其一即可，[-i] 为可登录到目标机的 root 用户（或 --user 指定的其他用户）的私钥，也可使用 [-p] 交互式输入该用户的密码。
  预期日志结尾输出 Deployed cluster tidb-test successfully 关键词，表示部署成功。

4.6、查看 TiUP 管理的集群情况

tiup cluster list
TiUP 支持管理多个 TiDB 集群，该命令会输出当前通过 TiUP cluster 管理的所有集群信息，包括集群名称、部署用户、版本、密钥信息等。

4.7、检查部署的 TiDB 集群情况

例如，执行如下命令检查 tidb-test 集群情况：

tiup cluster display tidb-test

预期输出包括 tidb-test 集群中实例 ID、角色、主机、监听端口和状态（由于还未启动，所以状态为 Down/inactive）、目录信息。

4.8、启动集群

安全启动是 TiUP cluster 从 v1.9.0 起引入的一种新的启动方式，采用该方式启动数据库可以提高数据库安全性。推荐使用安全启动。

安全启动后，TiUP 会自动生成 TiDB root 用户的密码，并在命令行界面返回密码。

注意
使用安全启动方式后，不能通过无密码的 root 用户登录数据库，你需要记录命令行返回的密码进行后续操作。

该自动生成的密码只会返回一次，如果没有记录或者忘记该密码，请参照忘记 root 密码修改密码。

方式一：安全启动

tiup cluster start tidb-test --init

预期结果如下，表示启动成功。

Started cluster `tidb-test` successfully.
The root password of TiDB database has been changed.
The new password is: 'y_+3Hwp=*AWz8971s6'.
Copy and record it to somewhere safe, it is only displayed once, and will not be stored.
The generated password can NOT be got again in future.

方式二：普通启动

tiup cluster start tidb-test

预期结果输出 Started cluster tidb-test successfully，表示启动成功。使用普通启动方式后，可通过无密码的 root 用户登录数据库。

4.9、验证集群运行状态

tiup cluster display tidb-test

预期结果输出：各节点 Status 状态信息为 Up 说明集群状态正常。

写在最后

在生产环境下部署时，需要大量的资源去部署，但是针对于TiDB的优点而言，缺点可以忽略。
TiDB优点：

1. 完全兼容 MySQL 协议，业务层几乎不需要改动。
2. 分布式存储，节点无限扩容，高可用。
3. 完美替代 MySQL 分库分表。
4. 大表 DDL不影响业务。
5. 支持事务，隔离级别为’快照级别隔离’ [见附录]。
6. 可兼容 CDC 链路。