TiDB-最小实践

最小拓扑生产级体验TiDB5.3.0 并升级到TiDBV5.4.0

一、说明

1.1 这篇文章出现的原因

自己在做调研、学习试用tidb的时候 苦于环境的要求（本机不方便实现最小拓扑），再有后来社区里一些同学们发了有关最小部署的疑问的帖子，鉴于上面2点，就想写点什么记录下来。

官方要求最小拓扑：

实例个数物理机配置IP配置TiDB316 VCore 32GB * 110.0.1.1 10.0.1.2 10.0.1.3默认端口 全局目录配置PD34 VCore 8GB * 110.0.1.4 10.0.1.5 10.0.1.6默认端口 全局目录配置TiKV316 VCore 32GB 2TB (nvme ssd) * 110.0.1.7 10.0.1.8 10.0.1.9默认端口 全局目录配置Monitoring & Grafana14 VCore 8GB * 1 500GB (ssd)10.0.1.10默认端口 全局目录配置1.2 疑问&目标

最小拓扑111 是否可以完成学习体验

最小拓扑111 能不能抗住小并发正常的读写，用于小型的单库应用

最小拓扑111 扩容之后是否于正常的部署标准拓扑无异

目标：验证上面的问题，并学习tidb安装、扩容、升级、压测

注：“拓扑111” 指的是1个tidb-server+1个pd+1个tikv，本文中此词未做特别声明的都做此解释 ！

1.3 本次测试环境1、主机win10 8G 4核 2、虚拟机centos7.3 4G内存 2核cpu - 中控机(tiup安装) - 集群所在的机器 - 宿主机到虚拟机的端口转发（宿主机:虚拟机） 20022:22,4000:400,2379:2379,3000:3000

二、拓扑111

既然是最小实践 就应该是拓扑111：1 tidb-server+1 pd+1 tikv

2.1 拓扑文件 cluster111.yml# cluster111.yml global: user: "tidb" ssh_port: 22 deploy_dir: "/tidb-deploy111" data_dir: "/tidb-data111" server_configs: tidb: log.slow-threshold: 300 tikv: readpool.storage.use-unified-pool: false readpool.coprocessor.use-unified-pool: true pd: replication.max-replicas: 1 pd_servers: - host: 10.0.2.15 client_port: 2379 #注意与tidb-server,tikv的key不一样 peer_port: 2380 #注意与tidb-server,tikv的key不一样 tidb_servers: - host: 10.0.2.15 port: 4000 status_port: 10080 tikv_servers: - host: 10.0.2.15 port: 20160 status_port: 20180

三、部署&压测

3.1 准备环境(centos7.3)

centos7.3环境的安装这里不做赘述。

# 调大 sshd 服务的连接数限制 # 修改 /etc/ssh/sshd_config 将 MaxSessions 调至 30。 sed -i s/#MaxSessions.*/MaxSessions 30/g /etc/ssh/sshd_config # 重启 sshd 服务 stystemctl restart sshd3.2 单IP部署最小拓扑111 v5.3.03.2.1 安装 cluster111# 安装tiup curl --proto =https --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh # 1、加载tiup组件 source /root/.bash_profile # 安装cluster组件 tiup cluster # 更新tiup、更新cluster tiup update --self && tiup update cluster # 2、帮助查看 tiup help tiup cluster 或 tiup cluster -h # 3、 查看 TiUP 支持的最新可用版本 tiup list tidb # 4、安装cluster111 # tiup cluster deploy <cluster-name> <tidb-version> ./topo.yaml --user root -ptiup cluster check ./cluster111.yml tiup cluster deploy cluster111 v5.3.0 ./cluster111.yml --user root -p#会提示输入密码 #提示输入y/n # 预估约10多分钟可以安装完毕 # 如果中间有终端可以重复执行 tiup cluster deploy cluster111 v5.3.0 ./cluster111.yml --user root -p # 提示 “Cluster `cluster111` deployed successfully, you can start it with command: `tiup cluster start cluster111 --init`” 表示安装成功 # 5、通过命令查看集群 tiup cluster list # 6、初始化集群 tiup cluster start cluster111 --init

注意：

使用tiup cluster start cluster111 --init 将给root用户生成随机密码

如果不加--init 将不生成随机密码

演示期间把密码修改为123456。ALTER USER root IDENTIFIED BY 123456;

3.2.2 使用命令查看集群情况tiup cluster list tiup cluster display cluster111

如上图：显示cluster111 启动成功

1、pd 是一个节点，并且是Leader，而且有dashboard

2、tidb-server和tikv都各一个节点

3.2.3 通过dashboard 查看集群情况

1、dashboard的默认地址是http://127.0.0.1:2379/dashboard/

打开dashboard的默认也如下：

2、实例信息：

3、主机：

4、SQL语句分析

5、慢查询、流量可视化、日志搜索都正常。

3.2.4 tidb相关命令

1、集群shell命令

tiup cluster show-config cluster111 tiup cluster display cluster111

2、查看config命令

shell>tiup ctl:v5.3.0 pd -u http://127.0.0.1:2379 config show shell>tiup ctl:v5.3.0 pd -u http://127.0.0.1:2379 config show scheduler

默认指向的pd 为 -uhttp://127.0.0.1:2379 可以省略

确认当前的最大副本数 msyql>show config msyql>show config where name=replication.max-replicas;

3、ctl shell命令

#pd-ctl tiup ctl:v5.3.0 pd help tiup ctl:v5.3.0 pd health

tiup ctl:v5.3.0 pd store #region数据量，leader数量，perr数量 tiup ctl:v5.3.0 pd scheduler tiup ctl:v5.3.0 pd scheduler show tiup ctl:v5.3.0 pd cluster tiup ctl:v5.3.0 pd region -h

tiup ctl:v5.3.0 pd region check miss-peer tiup ctl:v5.3.0 pd region check miss-peer #缺副本的 Region tiup ctl:v5.3.0 pd region check extra-peer #多副本的 Region tiup ctl:v5.3.0 pd region check down-peer #有副本状态为 Down 的 Region tiup ctl:v5.3.0 pd region check pending-peer #有副本状态为 Pending 的 Region

#进入ptcl 交互式 tiup ctl:v5.3.0 pd -u http://127.0.0.1:2379 -i

#tidb -ctl tiup ctl:v5.3.0 tidb help tiup ctl:v5.3.0 tidb keyrange --database test --table ttt #查找范围

#tikv-ctl tiup ctl:v5.3.0 tikv help tiup ctl:v5.3.0 tikv --pd 127.0.0.1:2379 compact-cluster

7、安装组件

# shell # 安装 组件 tiup ctl:v5.3.0 tiup bench3.4 压测

使用 TiUP bench 组件压测 TiDB

TPC-C 评测数据库的联机交易处理（OLTP）能力

TPC-H 通过 复杂SQL查询来评估数据库OLAP的性能

3.4.1 TPCC压测

tiup cluster display cluster111

说明：

WAREHOUSE 数据库中 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 记录。

可以粗鲁的估计1W的数据为10万。

1、1W压测

tiup bench tpcc -H 127.0.0.1 -p 123456 -P 4000 -D tpcc --warehouses 1 prepare

tiup bench tpcc -H 127.0.0.1 -p 123456 -P 4000 -D tpcc --warehouses 1 run

进行数据正确性验证。一共压测了10多个小时

[Summary] DELIVERY - Takes(s): 53449.3, Count: 14240, TPM: 16.0, Sum(ms): 8055695.8, Avg(ms): 560.7, 50th(ms): 469.8, 90th(ms): 872.4, 95th(ms): 1208.0, 99th(ms): 2080.4, 99.9th(ms): 4831.8, Max(ms): 4831.1 [Summary] NEW_ORDER - Takes(s): 53449.1, Count: 161134, TPM: 180.9, Sum(ms): 23554267.9, Avg(ms): 144.3, 50th(ms): 113.2, 90th(ms): 234.9, 95th(ms): 318.8, 99th(ms): 637.5, 99.9th(ms): 1677.7, Max(ms): 4831.1 [Summary] ORDER_STATUS - Takes(s): 53434.3, Count: 14315, TPM: 16.1, Sum(ms): 955242.2, Avg(ms): 66.8, 50th(ms): 50.3, 90th(ms): 121.6, 95th(ms): 167.8, 99th(ms): 335.5, 99.9th(ms): 738.2, Max(ms): 2415.9 [Summary] PAYMENT - Takes(s): 53448.7, Count: 154134, TPM: 173.0, Sum(ms): 17936546.0, Avg(ms): 97.2, 50th(ms): 75.5, 90th(ms): 159.4, 95th(ms): 218.1, 99th(ms): 436.2, 99.9th(ms): 1275.1, Max(ms): 4831.1 [Summary]PAYMENT_ERR - Takes(s): 53448.7, Count: 1, TPM: 0.0, Sum(ms): 282285.1, Avg(ms): 15837.7, 50th(ms): 16106.1, 90th(ms): 16106.1, 95th(ms): 16106.1, 99th(ms): 16106.1, 99.9th(ms): 16106.1, Max(ms): 4831.1 [Summary] STOCK_LEVEL - Takes(s): 53448.9, Count: 14572, TPM: 16.4, Sum(ms): 1332893.0, Avg(ms): 87.5, 50th(ms): 71.3, 90th(ms): 142.6, 95th(ms): 184.5, 99th(ms): 369.1, 99.9th(ms): 805.3, Max(ms): 4831.1 tpmC: 180.9, efficiency: 1406.6%

压测数据只供参考：TPCC 发压机器在虚拟机，压测期间做了其他的事项，影响测试结果。

2、10W压测 （百万数据）

tiup bench tpcc -H 127.0.0.1 -p 123456 -P 4000 -D tpcc --warehouses 10 prepare

tiup bench tpcc -H 127.0.0.1 -p 123456 -P 4000 -D tpcc --warehouses 10 run

3.4.2 TPCH压测tiup bench tpch --db tpch -P4000 -Uroot -p123456 --sf=1 prepare tiup bench tpch --db tpch -P4000 -Uroot -p123456 --sf=1 --check=true run

虚拟机压测oom 没有进行下去（没有截图）

3.5 Cluster111总结

1）在当前的配置下，比较很定 。

四、扩容 & 升级

4.1扩容监控节点4.1.1 扩容监控的拓扑# scale-out-cluster111-monitor.yml monitoring_servers: - host: 10.0.2.15 port: 9090 # ng_port: 12020 grafana_servers: - host: 10.0.2.15 port: 3000 alertmanager_servers: - host: 10.0.2.15 web_port: 9093 cluster_port: 90944.1.2 步骤与过程

执行扩容命令

tiup cluster scale-out cluster111 ./cluster111-scale-out-monoitor.yml -uroot -p #提示输入ssh密码

提示：scaled cluster xxx out successfully 说明扩容成功

4.1.3 结果验证4.1.3.1 shell命令验证集群情况tiup cluster show-config cluster111 tiup cluster display cluster111 4.1.3.2 dashboard验证

dashboard ->概况

界面有qps、duration的数据

其他界面没有变化

4.1.3.3 Grafana验证

http://127.0.0.1:3000

默认账号admin 默认密码admin

1、配置数据源：左侧选择configuration->Data Sources 出现后侧的可用数据源 ，双击cluster111数据源 进入测试数据源界面->Save&test 保存。

2、回到General /Home ，点击General 选择 cluster111-overview 打开

4.1.3 复盘

1、 扩容的指令执行的过程比较顺利，10多分钟执行完毕（几十万条数据库）。

2、这里出现一个插曲，误用 tiup cluster check

本意是检测扩展yaml文件有没有错误。使用tiup cluster check 扩容监控拓扑 ，提示 9100端口已经存在集群里误导了我才有这个插曲。

1）查看cluster11集群配置显示如下：·tiup cluster show-config cluster111

2）使用 tiup cluster check ./cluster111-scale-out-monoitor.yml 提示信息如下图

Error: Deploy port conflicts to an existing cluster (spec.deploy.port_conflict)

3）再次确认扩容配置如图：

4）又试了试 tiup cluster check ./cluster111-scale-out-tikv2-1.yml 也提示同样的错误

5）还是需要请教官方文档 查看官方文档：https://docs.pingcap.com/zh/tidb/stable/tiup-component-cluster-check

没有说check可以检错 扩容配置的功能。

总结：

1）我这里是误用（用错了地方）也就是 tiup cluster check 用错了场景了；

2）恰好我要做的扩容监控节点和提示的信息有相关，加深了误导。

4.2扩容1个tikv节点# cluster111-scale-out-tikv2-1.yml tikv_servers: - host: 10.0.2.15 port: 20161 status_port: 20181

tiup cluster display cluster111

tiup cluster scale-out cluster111 ./cluster111-scale-out-tikv2-1.yml -uroot -p

注意：

开启监控 tiup cluster start cluster111 -R alertmanager,grafana,prometheus 观察扩容前后的 peer数量，region数量

# 扩容前 # "region_count": 23, tiup ctl:v5.3.0 pd store #扩容后 # "region_count": 23, 新增的store上没有region tiup ctl:v5.3.0 pd store#查看当前的默认副本数 show config where name=replication.max-replicas; #显示为1 #设置副本数 set config 10.0.2.15:2379 `replication.max-replicas`=2; # 再次查看副本数数 show config where name=replication.max-replicas; #显示为1 # "region_count": 23, 新增的store上开始有region ，peer数为46个了（因为2个节点上的都一样） tiup ctl:v5.3.0 pd store 4.3 扩容1个tikv节点（总tikv节点达到3个）

思考 tikv3副本的意义是什么？

提高业务可用性和数据可靠性（分布式raft协议），如果一个节点挂掉，业务正常运行。

3个节点的3副本 本质上没有提高数据的横向扩展能力，如果需要提高数据库的横向能力需要增加更多的tikv节点。

扩容yaml

# cluster111-scale-out-tikv2-2.yml tikv_servers: - host: 10.0.2.15 port: 20162 status_port: 20182

tiup cluster scale-out cluster111 ./cluster111-scale-out-tikv2-2.yml -uroot -p

#当前的peer为46

升级完成过一会，发现peer没有变化，store变成了3个。

#查看当前的默认副本数 show config where name=replication.max-replicas; #显示为2 #设置副本数 set config 10.0.2.15:2379 `replication.max-replicas`=3; # 再次查看副本数数 show config where name=replication.max-replicas; #显示为3 # "region_count": 23, 新增的store上开始有region ，peer数为69个了（因为3个节点上的都一样） tiup ctl:v5.3.0 pd store

Peer数量变成了69个了，符合预期

说明一个问题：replication.max-replicas 控制着同一份数据的最大副本数量

tiup cluster display cluster111

如果 在当前的环境下，是3个节点，把 replication.max-replicas修改为1，peer数会减少吗？

说干就干：

#设置副本数 set config 10.0.2.15:2379 `replication.max-replicas`=1; show config where name=replication.max-replicas; tiup ctl:v5.3.0 pd store # 结果说明 peer数是往下掉的，没有掉到预期的23，而且是3个store上的都有掉的副本。（最终会掉到23个） 4.4升级到最新版（v5.4.0）4.4.1 升级tiup组件和cluster组件

tiup update --self && tiup update cluster

4.4.2 编辑 TiUP Cluster 拓扑配置文件

去掉不兼容的配置

# tiup cluster edit-config <cluster-name> tiup cluster edit-config cluster111 #修改完成后 :wq 保存并退出编辑模式，输入 Y 确认变更。4.4.3 检查当前集群的健康状况

tiup cluster check cluster111 --cluster

4.4.4升级集群到v5.4.0

tiup cluster upgrade cluster111 v5.4.0

tiup cluster display cluster111