作者： TiDBer_ 小阿飞原文来源：https://tidb.net/blog/18405945

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

第一部分  硬件资源

一、硬件资源

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

| | | | | | | || – | ———— | — | —– | —- | ——— | ————- || 序号 | IP | CPU | 存储 | 内存 | Hostname | 描述信息 || 1 | 21.72.124.38 | 16 核 | 300GB | 46g | tidb | SQL 解析层，不存储数据 || 2 | 21.72.124.39 | 8 核 | 300GB | 15g | pd | 管理模块，调度计算 || 3 | 21.72.124.40 | 16 核 | 300GB | 62g | tikv | 分布式存储模块，存储数据 || 4 | 21.72.124.41 | 48 核 | 300GB | 125g | tiflash | 列式存储，分析场景加速 || 5 | 21.72.124.42 | 16 核 | 200GB | 62g | ticdc | 增量数据同步工具 || 6 | 21.72.124.43 | 8 核 | 200GB | 15g | localhost | 管理节点 |

二、模块详解

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

第二部分  系统及软件资源

一、操作系统及对应软件

| | | | || – | —————– | ———————————————— | ———- || 序号 | 软件或包 | 名称 | 版本号 || 1 | 操作系统版本 | CentOS Linux release 7.8.2003(Core) | 7.8 || 2 | TiDB 软件包 | tidb-community-server-v6.5.2-linux-amd64.tar.gz | [V6.5.2]() || 3 | TiDB 工具包 | tidb-community-toolkit-v6.5.2-linux-amd64.tar.gz | V6.5.2 || 4 | 编译和构建 TiDB 所需的依赖库 | Golang | 1.19 || 5 | | Rust  nightly-2022-07-31 |   || 6 | | GCC | 7.X || 7 | | LLVM | 13.0 |

二、软件包说明

操作系统支持详见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 分钟