TIDB分布式数据库离线实施方案及相关测试（测试版）

第一部分  硬件资源

一、硬件资源

现有硬件资源环境统计如下

二、模块详解

1.TiDB Server

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

2.PD Server

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

3.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 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。

PS:TiKV底层为RocksDB,多版本并发控制 (MVCC)

4.TiFlash

TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

5.TiCDC(非必须模块)

TiCDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 可以将数据解析为有序的行级变更数据输出到下游。

6.Manager

第二部分  系统及软件资源

一、操作系统及对应软件

二、软件包说明

操作系统支持详见https://docs.pingcap.com/zh/tidb/v6.5/hardware-and-software-requirements

官方软件包和工具包下载：

https://cn.pingcap.com/product/#SelectProduct

依赖库（包）下载：

https://centos.pkgs.org/

第三部分  拓扑结构

一、官方架构图

二、物理结构图

说明：因最小化部署，每台服务器上部署了多个模块，此处模块名称是为区别每个模块的主节点而设置更改，无实际意义，正式环境每台服务器或多台服务器只能部署最多一个模块（管理节点除外）。

三、最小化节点部署模块分布详情

四、新增节点后扩容、缩容后模块分布详情

3PD \4TiDB \4TiKV \3TiFlash \1HA、manager

备注：A、B机房位于同城不同地点，直线距离约15公里

五、逻辑结构图

第四部分 TiDB及组件安装

一、基础环境检查

1.检查磁盘空间

命令：#df -h

生产环境官方建议：

2.检查内存

命令：

#free -g

生产环境官方建议：

3.检查CPU

命令：

#nproc

生产环境官方建议：

4.检查SWAP

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

free -g查看SWAP分配，并关闭SWAP

#echo "vm.swappiness = 0">> /etc/sysctl.conf

#swapoff -a && swapon -a

#sysctl -p

5.检查文件系统

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

操作如下：

（1）检查数据盘

#fdisk -l

（2）创建分区

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

（3）格式化文件系统

mkfs.ext4 /dev/vda3

此处如果报错，无法格式化，需执行 #partprobe命令同步内核参数

（4）查看UUID

#lsblk -f

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

vi /etc/fstab

添加挂载参数，UUID为上一步查出

UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data ext4 defaults,nodelalloc,noatime 0 2

（6）挂载数据盘

#mkdir /data &&

> mount -a

（7）检查文件系统是否生效

#mount -t ext4

6.tidb节点创建临时文件夹 

#sudo mkdir /tmp/tidb

#sudo chmod -R 777 /tmp/tidb/

二、系统相关服务

1.关闭防火墙

#systemctl stop firewalld.service

#systemctl disable firewalld.service

#systemctl status firewalld.service

2.关闭透明大页

# cat /sys/kernel/mm/transparent_hugepage/enabled

[always] madvise never

# echo never > /sys/kernel/mm/transparent_hugepage/enabled

# echo never > /sys/kernel/mm/transparent_hugepage/defrag

3.配置时间同步

(1)检查NTP服务是否开启

# systemctl status chronyd.service

(2)查看chrony服务是否同步

# chronyd tracking

(3)修改chrony服务，此处设置主控机（这里假设为21.72.124.43）作为时间同步服务器，先修改主控机（服务端）设置

# vi /etc/chrony.conf

添加allow 0.0.0.0/0 添加local stratum 10

注释掉上方的server iburst

(4)重启服务

# systemctl restart chronyd.service

(5) 其他所有节点，需同步主控机，各节点操作如下

# vi /etc/chrony.conf

注释server iburst，新增

server 21.72.124.43 iburst

重启

# systemctl restart chronyd.service

检查是否同步

# chronyc sources -v

4.修改sysctl.conf参数

所有节点服务器配置如下文件：

# vim /etc/sysctl.conf

添加以下内容：

fs.file-max = 1000000

net.core.somaxconn = 32768

net.ipv4.tcp_tw_recycle = 0

net.ipv4.tcp_syncookies = 0

vm.overcommit_memory = 1

生效

sysctl -p

5.修改limits.conf文件

所有节点服务器配置如下文件：

#  vim /etc/security/limits.conf

添加如下内容：

tidb           soft     nofile          1000000

tidb           hard    nofile           1000000

tidb           soft     stack           32768

tidb           hard     stack          32768

三、配置互信

1.创建tidb用户

每个节点以root用户创建tidb用户和密码

#useradd tidb

#passwd tidb

2.配置sudo免密

每个节点配置sudo免密

# visudo

添加以下内容

tidb ALL=(ALL) NOPASSWD:ALL

3.配置中控机到其他节点互信

中控机(21.72.124.43)以tidb用户登录，执行以下命令

ssh-keygen -t rsa

根据路径配置到各节点的互信

ssh-copy-id -i /home/tidb/.ssh/id_rsa.pub 21.72.124.39

ssh-copy-id -i /home/tidb/.ssh/id_rsa.pub 21.72.124.40

。。。。。。

4.测试互信

中控机tidb用户登录 直接ssh到节点

[tidb@localhost]# ssh 21.72.124.39

#sudo -su root

如果以上命令可登录39节点并可直接切换至root用户，表示sudo免密配置成功。

四、安装

1.上传、解压安装包

上传tidb安装包至中控机

tidb-community-server-v6.5.2-linux-amd64.tar.gz  

tidb-community-toolkit-v6.5.2-linux-amd64.tar.gz

2.安装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

3.合并离线包

如果是通过官方下载页面下载的离线软件包，需要将 TiDB-community-server 软件包和 TiDB-community-toolkit 软件包合并到离线镜像中。

执行以下命令合并离线组件到 server 目录下。${version}替换成版本号，例如：v6.5.2

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

4.创建配置文件

在中控机创建并配置topology.yaml文件,注意yaml文件格式，否则安装时，会报错和不识别

# vim topology.yaml

新增的yaml文件里添加配置模块信息

注：tikv节点至少3个，其他模块可混合部署

配置文件根据拓扑部署列出各模块所属节点，举例如下：

--global是全局变量配置，user用户名，ssh_port主机ssh端口号，deploy_dir部署文件夹位置，data_dir数据文件夹位置

--server_configs服务配置，将tidb日志级别选为info,慢阈值设为300

--monitoring_servers&grafana_servers&alertmanager_servers均部署到中控机节点

global:

  user: ＂tidb＂

  ssh_port: 22

  deploy_dir: ＂/tidb-deploy＂

  data_dir: ＂tidb-data＂

server_configs:

  tidb:

log.level:”info”

log.slow-threshold:300

pd_servers:

  - host: 21.72.124.39

  - host: 21.72.124.38

  - host: 21.72.124.42

tidb_servers:

  - host: 21.72.124.38

  - host: 21.72.124.39

tikv_servers:

  - host: 21.72.124.40

  - host: 21.72.124.42

  - host: 21.72.124.43

monitoring_servers:

  - host: 21.72.124.43

grafana_servers:

  - host: 21.72.124.43

alertmanager_servers:

  - host: 21.72.124.43

5.安装环境校验

使用tidb用户检查安装环境并自动修复集群存在的潜在风险，要确保修复完成后无Fail的项目，如修复完还有Fail项，需手动检查描述并根据Fail描述调整，调整完成重新执行检查，直到无Fail项为止。

检查风险项

#tiup cluster check ./topology.yaml --user tidb

检查并修复

# tiup cluster check ./topology.yaml --apply --user tidb

6.集群的安装部署

执行下列安装部署命令

# tiup cluster deploy tidb v6.5.2 ./topology.yaml --user tidb

--tidb为集群名称

--v6.5.2为部署的集群版本

--topology.yaml为初始部署集群拓扑文件

--user tidb表示以tidb用户登录到目标主机完成部署

五、初始化集群

1.查看 TiUP 管理的集群情况

# tiup cluster list

2.检查部署的 TiDB 集群情况

# tiup cluster display tidb

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

3.启动集群

# tiup cluster start tidb

最后输出以下内容，表示集群启动成功

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.

4.检查集群运行状态

# tiup cluster display tidb

--所有节点状态均为up表明正常。

5.Dashboard 和 Grafana 

(1)Dashboard

通过 {pd-ip}:{pd-port}/dashboard 登录 TiDB Dashboard，登录用户和口令为 TiDB 数据库 root 用户和口令。如果你修改过数据库的 root 密码，则以修改后的密码为准，默认密码为空。

例如本次部署登录地址为：

Dashboard

http://21.72.124.43:2379/dashboard

(2)Grafana

通过 {Grafana-ip}:3000 登录 Grafana 监控，默认用户名及密码为 admin/admin。

点击 Overview 监控页面检查 TiDB 端口和负载监控信息。

例如本次部署登录地址为：

Grafana

http://21.72.124.43:3000

6.dashboard监控面板指标项解释

QPS 该区域显示最近一小时整个集群的每秒成功和失败查询数量

数据库时间

Database Time by SQL Type

-database time: 每秒的总数据库时间

-sql_type: 每种 SQL 语句每秒消耗的数据库时间

Database Time by SQL Phase

-database time: 每秒的总数据库时间

-get token/parse/compile/execute: 4 个 SQL 处理阶段每秒消耗的数据库时间

execute 执行阶段为绿色，其他三个阶段偏红色系，如果非绿色的颜色占比明显，意味着在执行阶段之外数据库消耗了过多时间，需要进一步分析根源。

SQL Execute Time Overview

-execute time: execute 阶段每秒消耗的数据库时间

-tso_wait: execute 阶段每秒同步等待 TSO 的时间

-kv request type: execute 阶段每秒等待每种 KV 请求类型的时间，总的 KV request 等待时间可能超过 execute time，因为 KV request 是并发的。

绿色系标识代表常规的写 KV 请求（例如 Prewrite 和 Commit），蓝色系标识代表常规的读 KV 请求，其他色系标识需要注意的问题。例如，悲观锁加锁请求为红色，TSO 等待为深褐色。如果非蓝色系或者非绿色系占比明显，意味着执行阶段存在异常的瓶颈。例如，当发生严重锁冲突时，红色的悲观锁时间会占比明显；当负载中 TSO 等待的消耗时间过长时，深褐色会占比明显。

应用连接

Connection Count

-total：所有 TiDB 的连接数

-active connections：所有 TiDB 总的活跃连接数

Disconnection

-undetermined 不确定的连接数

-ok 确定的连接数

-error 错误的连接数

SQL数量

Query Per Second

-total

-alter tables

-analyze tables

-begin

-commit

-createdatabase

-createtable

-CreateUser

-CreatView

-Delete

-DescTable

-DropTable

-DropDatabase

-grant

-insert

-replace

-rollback

-savepoint

-select

-set

-show

-truncatetable

-update

-use

-other

Failed Queries

-parser 解析

-planner 计划

-schema 实例

-server 服务

-unknown 未知

Command Per Second

6.grafana面板指标解释

六、扩容、缩容

1.TiDB扩容

（1）新建yaml文件

# vim tidb-scales-out.yaml

加入以下内容，注意yaml文件格式

tidb_servers:

  - host: 21.72.124.45

（2）执行检查

# tiup cluster check tidb tidb-scales-out.yaml --cluster

（3）执行扩容

# tiup cluster scales-out tidb tidb-scales-out.yaml

显示Scaled cluster ‘tidb’ out successfully表示扩容成功。

（4）扩容后检查

# tiup cluster display tidb

2.PD扩容

（1）新建yaml文件

# vim pd-scales-out.yaml

加入以下内容，注意yaml文件格式

pd_servers:

  - host: 21.72.124.48

（2）执行检查

# tiup cluster check tidb pd-scales-out.yaml --cluster

（3）执行扩容

# tiup cluster scales-out tidb pd-scales-out.yaml

（4）扩容后检查

# tiup cluster display tidb

3.TiKV扩容

（1）新建yaml文件

# vim tikv-scales-out.yaml

加入以下内容，注意yaml文件格式

tikv_servers:

  - host: 21.72.124.50

（2）执行检查

# tiup cluster check tidb tikv-scales-out.yaml --cluster

（3）执行扩容

# tiup cluster scales-out tidb tikv-scales-out.yaml

（4）扩容后检查

# tiup cluster display tidb

4.TiFlash扩容

（1）开启PD的Placement Rules功能

# tiup ctl:v6.5.2 pd -u http://21.72.124.38:2379 config set enable-placement-rules true

（2）新建yaml文件

# vim tiflash-scales-out.yaml

加入以下内容，注意yaml文件格式

tiflash_servers:

  - host: 21.72.124.53

（3）执行检查

# tiup cluster check tidb tiflash-scales-out.yaml --cluster

（4）执行扩容

# tiup cluster scales-out tidb tiflash-scales-out.yaml

（5）扩容后检查

# tiup cluster display tidb

5.缩容

（1）下线tidb、PD

下线tidb 39节点

# tiup cluster scales-in tidb --node 21.72.124.39:4000

下线PD 38节点

# tiup cluster scales-in tidb --node 21.72.124.38:2379

（2）下线tikv、tiflash

tikv、tiflah下线为异步下线，下线过程较慢，待状态变为tombstone后，还需手动执行命令清理这些节点

下线tikv 40节点

# tiup cluster scales-in tidb --node 21.72.124.40:20160

下线tiflash 41节点

# tiup cluster scales-in tidb --node 21.72.124.41:9000

使用命令观察节点状态

# tidb cluster display tidb

待tikv、tiflash下线节点status变为tombstone后，执行以下命令清除下线节点

# tiup cluster prune tidb

该命令执行以下操作：

    停止节点服务

    清理节点相关数据文件

更新集群拓扑，移除已下线节点

注意事项：TiFlash节点下线前，需检查目前副本数，副本数需小于缩容后的节点数，否则，不可进行TiFlash节点的缩容操作。

tobe_left_nodes代表所容后的TiFlash节点数

查询命令：

select * from information_schema.tiflash_replica where REPLICA_COUNT >’tobe_left_nodes’;

如果查询结果为空，可进行缩容操作；

如果结果不为空，则需要修改相关表的副本数:

alter table <db-name>.<table-name> set tiflash replica ‘new_replica_num’;

再次执行查询命令，确保没有数据表的TiFlash副本数大于缩容后的节点数。

第五部分 相关测试及结果分析

一、sysbench测试

1.测试模式

单一节点测试后把结果相加，

注：安装HAproxy的集群无需单节点测试

后面章节会说明正式环境离线安装HAproxy的步骤和部署

测试tidb节点：21.72.124.38  21.72.124.39

2.mysql客户端安装

正常情况下，将兼容的mysql客户端安装包上传到中控机节点进行安装即可。

此次，使用Docker部署mysql客户端和sysbench工具包

3.创建测试库

# mysql -uroot -h21.72.124.38 -P4000

mysql>create database sbtset;

4.sysbench配置

创建配置文件（非必须），主要将数据库连接信息和测试并发等编辑好，方便后续测试简化

#vim config

mysql-host=

mysql-user=

mysql-db=

mysql-passwd=

mysql-port=

time=

threads=

report-interval=

5.导入测试数据

# sysbench --config-file=config oltp.point_select --tables=32 --table-size=10000000 prepare

6.lua测试

(1)Point select 测试命令

# sysbench --config-file=config oltp_point_select --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

(2)Update index 测试命令

# sysbench --config-file=config oltp_update_index --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

(3)Read-only 测试命令

# sysbench --config-file=config oltp_read_only --tables=32 --table-size=10000000 --db-ps-mode=auto --rand-type=uniform run

说明：/usr/share/sysbench目录里有部分已写好的lua测试文件，可根据情况进行测试，此次主要测试tidb数据库的DDL性能，故只测试了查询、update、数据读写。

二、TPC-C测试

1.说明和环境准备

TPC-C 是一个对 OLTP（联机交易处理）系统进行测试的规范，使用一个商品销售模型对 OLTP 系统进行测试，其中包含五类事务：

NewOrder – 新订单的生成

Payment – 订单付款

OrderStatus – 最近订单查询

Delivery – 配送

StockLevel – 库存缺货状态分析

在测试开始前，TPC-C Benchmark 规定了数据库的初始状态，也就是数据库中数据生成的规则，其中 ITEM 表中固定包含 10 万种商品，仓库的数量可进行调整，假设 WAREHOUSE 表中有 W 条记录，那么：

STOCK 表中应有 W * 10 万条记录（每个仓库对应 10 万种商品的库存数据）

DISTRICT 表中应有 W * 10 条记录（每个仓库为 10 个地区提供服务）

CUSTOMER 表中应有 W * 10 * 3000 条记录（每个地区有 3000 个客户）

HISTORY 表中应有 W * 10 * 3000 条记录（每个客户一条交易历史）

ORDER 表中应有 W * 10 * 3000 条记录（每个地区 3000 个订单），并且最后生成的 900 个订单被添加到 NEW-ORDER 表中，每个订单随机生成 5 ~ 15 条 ORDER-LINE 记录。

我们将以 1000 WAREHOUSE 为例进行测试。

TPC-C 使用 tpmC 值 (Transactions per Minute) 来衡量系统最大有效吞吐量 (MQTh, Max Qualified Throughput)，其中 Transactions 以 NewOrder Transaction 为准，即最终衡量单位为每分钟处理的新订单数。

本文使用 go-tpc 作为 TPC-C 测试实现

需提前安装TIUP BENCH程序

离线环境，需在TOOL工具包里找到bench的tar包解压使用

测试：

tiup bench -h

2.导入数据

导入数据通常是整个 TPC-C 测试中最耗时，也是最容易出问题的阶段。

在 shell 中运行 TiUP 命令：

tiup bench tpcc -H 21.72.124.38,21.72.124.39 -P 4000 -D tpcc --warehouses 1000 --threads 20 prepare

基于不同的机器配置，这个过程可能会持续几个小时。如果是小型集群，可以使用较小的 WAREHOUSE 值进行测试。

数据导入完成后，可以通过命令 tiup bench tpcc -H 21.72.124.38 -P 4000 -D tpcc --warehouses 4 check 验证数据正确性。

3.运行测试

运行测试的命令是：

tiup bench tpcc -H 21.72.124.38,21.72.124.39 -P 4000 -D tpcc --warehouses 1000 --threads 100 --time 10m run

运行过程中控制台上会持续打印测试结果：

[Current] NEW_ORDER - Takes(s): 4.6, Count: 5, TPM: 65.5, Sum(ms): 4604, Avg(ms): 920, 90th(ms): 1500, 99th(ms): 1500, 99.9th(ms): 1500

[Current] ORDER_STATUS - Takes(s): 1.4, Count: 1, TPM: 42.2, Sum(ms): 256, Avg(ms): 256, 90th(ms): 256, 99th(ms): 256, 99.9th(ms): 256

[Current] PAYMENT - Takes(s): 6.9, Count: 5, TPM: 43.7, Sum(ms): 2208, Avg(ms): 441, 90th(ms): 512, 99th(ms): 512, 99.9th(ms): 512

[Current] STOCK_LEVEL - Takes(s): 4.4, Count: 1, TPM: 13.8, Sum(ms): 224, Avg(ms): 224, 90th(ms): 256, 99th(ms): 256, 99.9th(ms): 256

...

运行结束后，会打印测试统计结果：

[Summary] DELIVERY - Takes(s): 455.2, Count: 32, TPM: 4.2, Sum(ms): 44376, Avg(ms): 1386, 90th(ms): 2000, 99th(ms): 4000, 99.9th(ms): 4000

[Summary] DELIVERY_ERR - Takes(s): 455.2, Count: 1, TPM: 0.1, Sum(ms): 953, Avg(ms): 953, 90th(ms): 1000, 99th(ms): 1000, 99.9th(ms): 1000

[Summary] NEW_ORDER - Takes(s): 487.8, Count: 314, TPM: 38.6, Sum(ms): 282377, Avg(ms): 899, 90th(ms): 1500, 99th(ms): 1500, 99.9th(ms): 1500

[Summary] ORDER_STATUS - Takes(s): 484.6, Count: 29, TPM: 3.6, Sum(ms): 8423, Avg(ms): 290, 90th(ms): 512, 99th(ms): 1500, 99.9th(ms): 1500

[Summary] PAYMENT - Takes(s): 490.1, Count: 321, TPM: 39.3, Sum(ms): 144708, Avg(ms): 450, 90th(ms): 512, 99th(ms): 1000, 99.9th(ms): 1500

[Summary] STOCK_LEVEL - Takes(s): 487.6, Count: 41, TPM: 5.0, Sum(ms): 9318, Avg(ms): 227, 90th(ms): 512, 99th(ms): 1000, 99.9th(ms): 1000

测试完成之后，也可以运行 tiup bench tpcc -H 172.16.5.140 -P 4000 -D tpcc --warehouses 4 check 进行数据正确性验证。

4.清理测试数据

tiup bench tpcc -H 21.72.124.38,21.72.124.39 -P 4000 -D tpcc --warehouses 4 cleanup

三、CH-benCHmark 测试

1.说明

在测试数据库性能时，经常需要对数据库进行压测，为了满足这一需求，TiUP 集成了 bench 组件。TiUP bench 组件提供多种压测的 workloads，命令分别如下：

tiup bench tpcc   # 以 TPC-C 作为 workload 压测

tiup bench tpch   # 以 TPC-H 作为 workload 压测

tiup bench ch     # 以 CH-benCHmark 作为 workload 压测

tiup bench ycsb   # 以 YCSB 作为 workload 压测

tiup bench rawsql # 以自定义 SQL 文件作为 workload 压测

其中 tpcc, tpch, ch, rawsql 支持如下命令行参数。ycsb 使用方法较为不同，它主要通过 properties 文件进行配置，详见 go-ycsb 使用说明。

  -t, --acThreads int         OLAP 并发线程数，仅适用于 CH-benCHmark (默认 1)

                               --conn-params string    数据库连接参数，例如：

                              `--conn-params tidb_isolation_read_engines='tiflash'` 设置 TiDB 通过 TiFlash 进行查询

                              `--conn-params sslmode=disable` 设置连接 PostgreSQL 不启用加密

      --count int             总执行次数，0 表示无限次

  -D, --db string             被压测的数据库名 (默认为 "test")

  -d, --driver string         数据库驱动: mysql, postgres (默认 "mysql")

      --dropdata              在 prepare 数据之前清除历史数据

  -h, --help                  输出 bench 命令的帮助信息

  -H, --host strings          数据库的主机地址 (默认 ["127.0.0.1"])

      --ignore-error          忽略压测时数据库报出的错误

      --interval duration     两次报告输出时间的间隔 (默认 10s)

      --isolation int         隔离级别 0：Default，1：ReadUncommitted,

                              2：ReadCommitted，3：WriteCommitted，4：RepeatableRead，

                              5：Snapshot，6：Serializable，7：Linerizable

      --max-procs int         Go Runtime 能够使用的最大系统线程数

      --output string         输出格式 plain，table，json (默认为 "plain")

  -p, --password string       数据库密码

  -P, --port ints             数据库端口 (默认 [4000])

      --pprof string          pprof 地址

      --silence               压测过程中不打印错误信息

  -S, --statusPort int        TiDB 状态端口 (默认 10080)

  -T, --threads int           压测并发线程数 (默认 16)

      --time duration         总执行时长 (默认 2562047h47m16.854775807s)

  -U, --user string           压测时使用的数据库用户 (默认 "root")

--host 和 --port 支持以逗号分隔传入多个值，以启用客户端负载均衡。例如，当指定 --host 172.16.4.1,172.16.4.2 --port 4000,4001 时，负载程序将以轮询调度的方式连接到 172.16.4.1:4000, 172.16.4.1:4001, 172.16.4.2:4000, 172.16.4.2:4001 这 4 个实例上。

--conn-params 需要符合 query string 格式，不同数据库支持不同参数，

如：

--conn-params tidb_isolation_read_engines='tiflash' 设置 TiDB 通过 TiFlash 进行查询。

--conn-params sslmode=disable 设置连接 PostgreSQL 不启用加密。

当运行 CH-benCHmark 时，可以通过 --ap-host, --ap-port, --ap-conn-params 来指定独立的 TiDB 实例用于 OLAP 查询。

2.使用 TiUP 运行 TPC-C 测试

TiUP bench 组件支持如下运行 TPC-C 测试的命令和参数：

Available Commands:

      check       检查数据一致性

      cleanup     清除数据

      prepare     准备数据

      run         开始压测

Flags:

      --check-all            运行所有的一致性检测

      -h, --help                 输出 TPC-C 的帮助信息

      --partition-type int   分区类型 (默认为 1)

                             1 代表 HASH 分区类型

                             2 代表 RANGE 分区类型

                             3 代表 LIST 分区类型并按 HASH 方式划分

                             4 代表 LIST 分区类型并按 RANGE 方式划分

      --parts int            分区仓库的数量 (默认为 1)

      --warehouses int       仓库的数量 (默认为 10)

3.TPC-C 测试步骤

以下为简化后的关键步骤。完整的测试流程可以参考如何对 TiDB 进行 TPC-C 测试

通过 HASH 使用 4 个分区创建 4 个仓库：

tiup bench tpcc --warehouses 4 --parts 4 prepare

运行 TPC-C 测试：

tiup bench tpcc --warehouses 4 --time 10m run

检查一致性：

tiup bench tpcc --warehouses 4 check

清理数据：

tiup bench tpcc --warehouses 4 cleanup

当需要测试大数据集时，直接写入数据通常较慢，此时可以使用如下命令生成 CSV 数据集，然后通过 TiDB Lightning 导入数据。

生成 CSV 文件：

tiup bench tpcc --warehouses 4 prepare --output-dir data --output-type=csv

为指定的表生成 CSV 文件：

tiup bench tpcc --warehouses 4 prepare --output-dir data --output-type=csv --tables history,orders

4.使用 TiUP 运行 TPC-H 测试

TiUP bench 组件支持如下运行 TPC-H 测试的命令和参数：

Available Commands:

  cleanup     清除数据

  prepare     准备数据

  run         开始压测

Flags:

      --check            检查输出数据，只有 scale 因子为 1 时有效

  -h, --help             tpch 的帮助信息

      --queries string   所有的查询语句

      --sf int           scale 因子

5.TPC-H 测试步骤

（1）准备数据

tiup bench tpch --sf=1 prepare

运行 TPC-H 测试，根据是否检查结果执行相应命令：

（2）检查结果

tiup bench tpch --count=22 --sf=1 --check=true run

（3）不检查结果

tiup bench tpch --count=22 --sf=1 run

（4）清理数据

tiup bench tpch cleanup

6.使用 TiUP 运行 YCSB 测试

你可以使用 TiUP 对 TiDB 和 TiKV 节点分别进行 YCSB 测试。

（1）测试 TiDB

准备数据：

tiup bench ycsb load tidb -p tidb.instances="127.0.0.1:4000" -p recordcount=10000

运行 YCSB 测试：

# 默认读写比例为 95:5

tiup bench ycsb run tidb -p tidb.instances="127.0.0.1:4000" -p operationcount=10000

（2）测试 TiKV

（1）准备数据：

tiup bench ycsb load tikv -p tikv.pd="127.0.0.1:2379" -p recordcount=10000

（2）运行 YCSB 测试：

# 默认读写比例为 95:5

tiup bench ycsb run tikv -p tikv.pd="127.0.0.1:2379" -p operationcount=10000

7.使用 TiUP 运行 RawSQL 测试

你可以将 OLAP 查询写到 SQL 文件中，通过 tiup bench rawsql 执行测试，步骤如下：

（1）准备数据和需要执行的查询：

-- 准备数据

CREATE TABLE t (a int);

INSERT INTO t VALUES (1), (2), (3);

-- 构造查询，保存为 demo.sql

SELECT a, sleep(rand()) FROM t WHERE a < 4*rand();

（2）运行 RawSQL 测试

tiup bench rawsql run --count 60 --query-files demo.sql

四、节点增删性能测试

1.混合节点

（1）混合节点构成

3PD+2tidb+3tikv+2tiflash

（2）测试

插入数据

tiup bench tpcc -H 21.72.124.38,21.72.124.42 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计：9.2GB

插入数据用时：11min

TIKV分配数据：

21.72.124.39： 7.9GB

21.72.124.42： 6.9GB

21.72.124.43： 8.5GB

合计：23.3GB

TOP SQL用时:16min

TOP SQL语句：

SELECT

c_id,

c_last,

sum(ol_amount) as revenue,

c_city,

c_phone,

n_name

FROM

customer,

orders,

order_line,

nation

WHERE

  c_id = o_c_id and

  c_w_id = o_w_id and

  c_d_id = o_d_id and

  ol_w_id = o_w_id and

  ol_d_id = o_d_id and

  ol_o_id = o_id and

  o_entry_d >= ‘2007-01-02 00:00:00.000000’ and

  o_entry_d <= ol_delivery_d and

  n_nationkey = ascii(substr(c_stat,1,1)) -65

GROUP BY

  c_id,c_last,c_city,c_phone,n_name

ORDER BY

  revenue DESC;

（3）清理数据

# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

清理数据时间约10秒，可忽略不计。

TIKV数据盘数据自动清理

通过GC机制删除TIKV节点数据大约需要1-2小时，按每10分钟运行一次GC的频率，并会有相关日志生成。

2.扩容一个PD节点

（1）扩容

扩容操作参照本文档（第四部分第六项），新增节点扩容需配置主机，具体参考本文档（第四部分第一、二、三项）

（2）测试

插入数据同上

tiup bench tpcc -H 21.72.124.38,21.72.124.42 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计：9.2GB

插入数据用时：11min

TIKV数据：38.76GB

清理数据# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

TIKV数据盘数据自动清理用时40-1.5小时，因GC机制根据PD返回的命令，只访问其中一个数据节点，各节点数据清理时间有差异。

（3）结论

扩容PD节点对数据插入用时无差别，但对TIKV节点的数据存储和节点分配有影响。

3.扩容一个TIKV节点

（1）扩容

扩容操作参照本文档（第四部分第六项），新增节点扩容需配置主机，具体参考本文档（第四部分第一、二、三项）

（2）测试

插入数据同上

tiup bench tpcc -H 21.72.124.38,21.72.124.42 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计：9.2GB

插入数据用时：10min

TIKV数据：38.2GB

清理数据# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

TIKV数据盘数据自动清理用时40-1.5小时，因GC机制根据PD返回的命令，只访问其中一个数据节点，各节点数据清理时间有差异。

（3）结论

扩容TIKV节点对数据插入用时无差别，但对TIKV节点的数据存储和存储时间变化有影响。

4.3PD+4TIDB+6TIKV+3TIFLASH（无混合节点）

（1）扩容

扩容操作参照本文档（第四部分第六项），新增节点扩容需配置主机，具体参考本文档（第四部分第一、二、三项）

（2）测试

插入数据同上,四tidb节点同时参与导入

tiup bench tpcc -H 21.72.124.38,21.72.124.45,21.72.124.46,21.72.124.47 -P 4000 -D tpcc --warehouses 100 -threads 100 prapare

插入数据量统计：9.2GB

插入数据用时：6min

TIKV数据：32GB

清理数据# tiup bench tpcc -H 21.72.124.38 -P 4000 --warehouses 4 cleanup

TIKV数据盘数据自动清理用时40-1.5小时，因GC机制根据PD返回的命令，只访问其中一个数据节点，各节点数据清理时间有差异。

（3）结论

数据导入速度提升明显，导入用时提升一倍，TIKV数据写入趋于平缓大约用时12分钟