黄东旭解析 TiDB 的核心优势
902
2023-11-24
TiDB实践安装及性能测试(上)
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/
第三部分 拓扑结构
一、官方架构图
二、物理结构图
说明：因最小化部署，每台服务器上部署了多个模块，此处模块名称是为区别每个模块的主节点而设置更改，无实际意义，正式环境每台服务器或多台服务器只能部署最多一个模块（管理节点除外）。
三、最小化节点部署模块分布详情
序号
IP
部署模块
1
21.72.124.38
TIDB\TIFLASH
2
21.72.124.39
PD\TIKV
3
21.72.124.40
PD
4
21.72.124.41
TIFLASH
5
21.72.124.42
PD\TIDB\TIKV\TICDC
6
21.72.124.43
TIKV\ALERTMANAGER\PROMETHEUS\GRAFANA
四、新增节点后扩容、缩容后模块分布详情
3PD \4TiDB \4TiKV \3TiFlash \1HA、manager
备注：A、B机房位于同城不同地点，直线距离约15公里
序号
IP
部署模块
CPU(C)
MEM(g)
Storge(GB)
机房
1
21.72.124.38
TiDB
16
46g
300
A
2
21.72.124.39
PD
8
15g
300
A
3
21.72.124.40
TiKV
16
62g
300
A
4
21.72.124.41
TiFlash
48
125g
300
A
5
21.72.124.42
TiCDC/HAproxy
16
62g
200
A
6
21.72.124.43
manager
8
15g
200
A
7
21.72.124.45
TiDB
8
15
200
A
8
21.72.124.46
TiDB
8
15
200
B
9
21.72.124.47
TiDB
8
15
200
B
10
21.72.124.48
PD
4
15
200
A
11
21.72.124.49
PD
4
15
200
B
12
21.72.124.50
TiKV
8
31
500
A
13
21.72.124.51
TiKV
8
31
500
B
14
21.72.124.52
TiKV
8
31
500
B
15
21.72.124.53
TiFlash
32
62
200
A
16
21.72.124.54
TiFlash
32
62
200
B
17
预留
18
预留
19
预留
五、逻辑结构图
第四部分 TiDB及组件安装
一、基础环境检查
1.检查磁盘空间
命令：#df -h
生产环境官方建议：
组件
硬盘类型
实例数量(最低要求)
TiDB
***
2
PD
***
3
TiKV
***
3
TiFlash
1 or more ***s
2
TiCDC
***
2
监控
SAS
1
2.检查内存
命令：
#free -g
生产环境官方建议：
组件
内存
实例数量(最低要求)
TiDB
48 GB+
2
PD
16 GB+
3
TiKV
64 GB+
3
TiFlash
128 GB+
2
TiCDC
64 GB+
2
监控
16 GB+
1
3.检查CPU
命令：
#nproc
生产环境官方建议：
组件
CPU
实例数量(最低要求)
TiDB
16 核+
2
PD
8 核+
3
TiKV
16 核+
3
TiFlash
48 核+
2
TiCDC
16 核+
2
监控
8 核+
1
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 类型的 *** 磁盘存储 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` 设置连接 *** 不启用加密
--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 设置连接 *** 不启用加密。
当运行 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
序号
IP
部署模块
1
21.72.124.38
TIDB\TIFLASH
2
21.72.124.39
PD\TIKV
3
21.72.124.40
PD
4
21.72.124.41
TIFLASH
5
21.72.124.42
PD\TIDB\TIKV
6
21.72.124.43
TIKV
（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分钟
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
相关文章
