背景
目前大环境下,需有效利用现有机器资源来支撑业务应用的数据读写存储;多点现有TiDB集群大都是NVME SSD高配机器,TiDB库场景多,其中就有QPS低但消耗空间大(逻辑数据量17T,6 tikv机器共22T磁盘,业务应用对查询延迟不敏感)的某TiDB集群(冷热分离类场景,MySQL热数据->TiDB冷数据),准备把该集群迁移至IDC 4台48C 万兆网卡共180T RAID10 SAS机器(每台机器250G内存,3*15T data盘,每data12块盘,每块盘8T)
机器性能测试表现
IDC RAID0、RAID10 SAS机器IO吞吐性能表现:随机读写吞吐差,顺序读写吞吐和nvme机器差不多
使用fio进行测试,RAID10(镜像+分片)机器是现有SAS机器测试,RAID0(分片)找运维支持单独格式化了台机器
nvme ssd机器 (现TiDB集群) |
RAID0 idc sas机器 |
RAID10 idc sas机器 |
|
随机读 |
1284MB/s |
11.2MB/s |
18.0MB/s |
随机写 |
1281MB/s |
11.3MB/s |
18.9MB/s |
顺序写 |
381MB/s |
343MB/s |
352MB/s |
顺序读 |
928MB/s |
1316MB/s |
1062MB/s |
部署方案
- 每台机器250G内存按使用率70%,可使用内存175G;每台机器磁盘共45T按使用率70%,可使用磁盘31T
- 内部评估讨论下来使用方案三:3 TiDB集群 1TiKV节点/15T data盘,部署维护相对简单,不用配置Placement Rules
TiKV内存block_cache_size需要比理论70%内存水位消耗的block_cache_size小,TiKV节点非block_cache部分会消耗一定内存(如理论1TiKV block_cache_size 50GB,实践配置1TiKV block_cache_size 40GB)
方案一:1 TiDB大集群 2TiKV节点/ 15T data盘
- 每机器部署8个组件(6 tikv+1 tidb+1pd),tikv三副本,内存限制25G(block_cache_size=25G),tikv 25G*6 + tidb 25G=175G(70%内存水位),pd基本不消耗内存
- 1个TiDB大集群,每15T data盘放2 TiKV节点
优点
- 1个tidb大集群多库部署简单,运维管理方便
- 1套大集群能使用空间180T*70%=126T
- 同台机器3块RAID10 data盘最多允许宕3块不同盘
限制
- 单tikv空间最大可到10T(最大70%利用率),单tikv region多导致tikv<->pd、tikv region<->tikv region之前网络心跳压力大,需调大单region size,限制region最大key数量,开启region静默减少网络压力
- 需开启Placement Rules保证tikv相同副本在不同机器上
- 1集群多库存在某库大查询影响其它库
方案二:3 TiDB集群 1TiKV节点/ 8T data盘
- 每机器6个tikv资源池(每个tikv资源池8T),初始每机器3 tikv+1 tidb+1pd,tikv三副本,内存限制20G(block_cache_size=20G),tikv 20G*6 + tidb 25G=145G < 175G(70%内存水位)
- 需要运维把每台机器3块15T RAID10盘拆分为6块8T RAID1盘(镜像)
- 暂部署3套集群后续磁盘利用高可扩容资源池中另外12个tikv
优点
- 不同集群放不同data盘,可实现IO资源隔离
- 另外12个buffer tikv资源池可动态扩容进初始3套集群中
限制
- 需开启Placement Rules保证tikv相同副本在不同机器上
- 单tikv空间最大可到5T(最大70%利用率),单tikv region多导致tikv<->pd、tikv region<->tikv region之前网络心跳压力大,需调大单region size,限制region最大key数量,开启region静默减少网络压力
- 4台机器支撑2套TiDB集群计算节点(每套部署2计算节点),第3套TiDB集群计算节点部署在另外的2台MySQL SAS上
- RAID1 IO性能有一定下降,同台机器最多允许宕6块盘
方案三:3 TiDB集群 1TiKV节点/15T data盘(使用)
- 每机器部署3个组件(3 tikv+1 tidb+1pd),tikv三副本,内存限制50G(block_cache_size=50G),tikv 50G*3 + tidb 25G=175G(70%内存水位),pd基本不消耗内存
- 3个TiDB集群,每15T data盘放1 TiKV节点
优点
- 3个TiDB集群多库运维管理方便,不用配置Placement Rules
- 不同集群放不同data盘,可实现IO资源隔离
- 3套集群每套集群能使用空间45T*70%=31T
- RAID10最多允许宕3块不同盘
限制
- 单tikv空间最大可到10T,单tikv region多导致tikv<->pd、tikv region<->tikv region之前网络心跳压力大,需调大单region size,限制region最大key数量,开启region静默减少网络压力
- 4台机器支撑2套TiDB集群计算节点(每套部署2计算节点),第3套TiDB集群计算节点部署在另外的2台MySQL SAS上
- 相同集群多库存在某库大查询影响其它库
方案四:1 TiDB大集群 1TiKV节点/ 4T data盘
- 每机器部署14个组件(12 tikv+1 tidb+1pd),tikv三副本(五副本的话还差一台SAS机器),内存限制10G(block_cache_size=10G),tikv 10G*12 + tidb 25G=145G(70%内存水位),pd基本不消耗内存
- 1个TiDB集群,每4T data盘放1 TiKV节点(需要运维把3个15T盘拆分为12个4T盘,12块8T盘组成大RAID10,再分12个4T区)
优点
- 1个TiDB集群多库部署方便,运维管理方便
- 1套大集群能使用空间180T*70%=126T
- 不需要调整region size,region最大key数量
限制
- 单tikv空间最大4T,单tikv region少,tikv<->pd、tikv region<->tikv region之前网络心跳压力小
- 需开启Placement Rules保证tikv相同副本在不同机器上
- RAID10分12区不同盘性能可能有耦合风险
- 相同集群多库存在某库大查询影响其它库
SAS TiDB性能测试表现
根据原默认96MB region大小比例调整以下配置减小单tikv region数过多时造成的网络心跳压力
show config where name like '%region%size%';
show config where name like '%region%key%';
#修改Region 容量空间的最大值,分裂后新 Region 的大小
set config tikv `coprocessor.region-max-size`=384*1024*1024;
set config tikv `coprocessor.region-split-size`=256*1024*1024;
#修改Region 最多允许的 key 的个数,分裂后新 Region 的 key 的个数
set config tikv `coprocessor.region-max-keys`=3840000;
set config tikv `coprocessor.region-split-keys`=2560000;
set config pd `schedule.max-merge-region-keys`=533333;
tiup edit config配置
tikv:
coprocessor.region-max-keys: 3840000
coprocessor.region-max-size: 402653184
coprocessor.region-split-keys: 2560000
coprocessor.region-split-size: 268435456
readpool.unified.min-thread-count: 4
rocksdb.max-background-jobs: 20
storage.block-cache.capacity: 53687091200
sysbench通用测试
版本:v5.1.2
- Region size 96MB和Region size 256MB
- Sysbench 读写模式、只读模式、只写模式下, region size 256MB在分别5,10,20,30,40,80,120并发线程测试10分钟表现均符合预期
读写模式(region size)/线程数/QPS |
5 |
10 |
20 |
30 |
40 |
80 |
120 |
read_write(96MB) |
4108 |
7628 |
13634 |
20660 |
27515 |
46282 |
58736 |
read_write ( 256MB) |
4175 |
7818 |
14239 |
21011 |
28759 |
48255 |
60651 |
read_only (96MB) |
5085 |
10130 |
24445 |
39619 |
47790 |
65741 |
71250 |
read_only (256MB) |
5167 |
10363 |
24165 |
40395 |
48737 |
66297 |
70906 |
write_only (96MB) |
4529 |
7891 |
13578 |
19374 |
24946 |
40995 |
51733 |
write_only (256MB) |
4621 |
8344 |
14618 |
20468 |
26560 |
44066 |
55339 |
96MB和256MB下表region 相关信息
SELECT db_name,table_name,count(*) as table_region_num,sum(APPROXIMATE_SIZE)/count(*) as avg_region_size,sum(APPROXIMATE_KEYS)/count(*) as avg_keys FROM information_schema.tikv_region_status where db_name not in ('mysql','PERFORMANCE_SCHEMA','METRICS_SCHEMA','INFORMATION_SCHEMA') group by db_name,table_name;
+---------+------------+------------------+-----------------+-------------+
| db_name | table_name | table_region_num | avg_region_size | avg_keys |
+---------+------------+------------------+-----------------+-------------+
| test_1 | sbtest1 | 7 | 89.2857 | 731070.7143 |
| test_1 | sbtest19 | 7 | 87.0000 | 680148.1429 |
| test_1 | sbtest9 | 7 | 84.8571 | 599431.1429 |
| test_1 | sbtest16 | 7 | 86.2857 | 647396.8571 |
| test_1 | sbtest2 | 7 | 86.4286 | 628656.5714 |
| test_1 | sbtest12 | 8 | 78.7500 | 640271.1250 |
| test_1 | sbtest17 | 7 | 89.7143 | 711358.2857 |
| test_1 | sbtest20 | 7 | 91.0000 | 735381.0000 |
| test_1 | sbtest5 | 7 | 93.4286 | 753170.1429 |
| test_1 | sbtest11 | 7 | 87.2857 | 627783.2857 |
| test_1 | sbtest18 | 7 | 90.1429 | 730895.2857 |
| test_1 | sbtest10 | 7 | 91.5714 | 721825.0000 |
| test_1 | sbtest3 | 7 | 91.7143 | 652131.2857 |
| test_1 | sbtest4 | 7 | 84.8571 | 601430.5714 |
| test_1 | sbtest15 | 7 | 83.8571 | 582848.1429 |
| test_1 | sbtest7 | 7 | 91.1429 | 693512.8571 |
| test_1 | sbtest6 | 7 | 88.1429 | 651794.1429 |
| test_1 | sbtest14 | 7 | 74.4286 | 531716.5714 |
| test_1 | sbtest13 | 8 | 78.5000 | 640412.0000 |
| test_1 | sbtest8 | 7 | 86.0000 | 623834.4286 |
+---------+------------+------------------+-----------------+-------------+
+---------+------------+------------------+-----------------+--------------+
| db_name | table_name | table_region_num | avg_region_size | avg_keys |
+---------+------------+------------------+-----------------+--------------+
| test_1 | sbtest6 | 3 | 291.0000 | 2189007.3333 |
| test_1 | sbtest3 | 3 | 212.3333 | 1812167.3333 |
| test_1 | sbtest4 | 3 | 287.3333 | 2223480.0000 |
| test_1 | sbtest15 | 3 | 281.3333 | 2144375.0000 |
| test_1 | sbtest7 | 3 | 290.3333 | 2462079.0000 |
| test_1 | sbtest5 | 3 | 288.3333 | 2139456.0000 |
| test_1 | sbtest11 | 3 | 289.6667 | 2180768.3333 |
| test_1 | sbtest20 | 3 | 270.0000 | 2054470.3333 |
| test_1 | sbtest17 | 4 | 184.2500 | 1532379.5000 |
| test_1 | sbtest10 | 3 | 284.3333 | 2169171.3333 |
| test_1 | sbtest18 | 4 | 165.7500 | 1231921.0000 |
| test_1 | sbtest12 | 3 | 283.6667 | 2148944.3333 |
| test_1 | sbtest19 | 3 | 273.0000 | 2061119.0000 |
| test_1 | sbtest9 | 3 | 288.6667 | 2451287.6667 |
| test_1 | sbtest2 | 4 | 169.2500 | 1255160.2500 |
| test_1 | sbtest1 | 3 | 282.0000 | 2166915.3333 |
| test_1 | sbtest16 | 3 | 283.6667 | 2176474.3333 |
| test_1 | sbtest14 | 3 | 310.0000 | 2602663.3333 |
| test_1 | sbtest8 | 3 | 283.3333 | 2137327.6667 |
| test_1 | sbtest13 | 3 | 274.3333 | 2112638.3333 |
+---------+------------+------------------+-----------------+--------------+
SSD TiDB&SAS TiDB业务应用SQL测试
SAS TiDB 4个业务应用库仅有部分历史数据,用来验证SSD TiDB和SAS TiDB SQL查询延迟
库名 |
ware_xxx |
dmall_xxx |
dmall_xxx |
dmall_xxx |
当前SSD TiDB 查询延迟 |
1.8S |
60ms |
80ms |
60ms |
SAS TiDB查询延迟 |
3.0S |
100ms |
120ms |
110ms |
只读查询SQL |
select_ware_xxx.txt SQL使用的联合索引不是最优 |
select_dmall_xxx.txt |
select_dmall_xxx (2).txt |
select_dmall_xxx (3).txt |
单独备份部分表还原到SAS上验证SQL性能
create user dumpling@'10.%' identified by 'xxxxx';
grant SELECT,RELOAD,LOCK TABLES,REPLICATION CLIENT on *.* to dumpling@'10.%' ;
cd /root/tidb-toolkit-v5.2.0-linux-amd64/bin
./dumpling -u dumpling \
-P 4000 \
-h 10.xxxx \
-p xxxxxx \
-B xxxx\
--filetype sql \
--threads 15 \
-o /data2/xxxx \
-F 256
./tidb-lightning -config=/root/tidb-lightning.toml --check-requirements=false
扩展区NVME SSD TiDB迁移
TiDB相关组件迁移
- 4台SAS机器/data1盘扩容进现有集群,组成10个TiKV存储大集群
- 在其中3台SAS机器上扩容3个pd元数据节点,2台SAS机器上扩容2个tidb计算节点,1台SAS机器上扩容grafana&prometheus
- 再把SSD机器(pd节点、tidb节点、grafana&prometheus)缩容(pd-ct提前切换pd leader至SAS机器)只剩SAS机器实现扩展区SSD TiDB库迁移至IDC SAS机器
- 因为不是单独新部署的一套TiDB集群,就没有调整SAS机器TiDB集群region size, region keys(参数扩容、缩容方式迁移和原有SSD TiDB集群保持了默认一致)
TiDB DNS解析修改
- 修改tidb域名解析至SAS机器tidb计算节点
- 该步骤在SAS机器扩容进集群后
DRC同步修改
- 自研DRC同步工具修改mysql->tidb 目标tidb地址,因目标tidb地址是域名,重启DRC同步链路后重新解析tidb域名至SAS机器tidb计算节点
- 该步骤在SAS机器扩容进集群后
tiup中控配置迁移
#SSD 机器中控机
cd /root/
tar czvf tiup.tar.gz .tiup 压缩tiup中控配置
#SAS 机器中控机
scp tiup.tar.gz迁移至idc sas 10.xxxxx /root机器并解压
~/.bashrc 添加export PATH=/root/.tiup/bin:$PATH ,source ~/.bashrc
idc sas机器都添加sshd_config allowusers
sas中控机分别ssh-copy-id 新中控机10.xxxxx 公钥至目标机器
sas机器tiup display, restart grafana&prometheus验证功能是否正常
SAS 机器扩容进现有集群后,高峰期SAS机器磁盘性能利用率相比SSD机器大
SAS机器:
SSD机器:
后续表现
后期SAS机器TiDB性能表现,P999延迟有秒级别~几十秒,业务应用方也能接受查TiDB冷数据延迟时间
Raft store cpu使用率高峰期超过110%左右,raftstore.store-pool-size 参考值 官方参考值为raftstore.store-pool-size(默认2) * 85% = 45%左右,后续增大store_pool_size后再持续观察raft store cpu使用率
总结
- NVME SSD TiDB集群迁移至4台SAS机器后节省了6 tikv机器+3 ( tidb+pd )机器,单集群共42T(70%磁盘水位算)大容量SAS TiDB也对低QPS(业务查询延迟时间不敏感)数据需长期保存业务场景提供有力支撑保障
- 加强和业务应用方协作,不同业务场景TiDB适配不同存储(NVME SSD机器 or SAS机器)
- 单机器多TiKV情况下block_cache_size内存、磁盘使用上和各组件端口占用方面需提前规划好
- 单TiKV大磁盘情况region size、region keys可根据实际测试效果适当增大