TiDB 落地SAS机器实践

作者： jiaxin 原文来源： https://tidb.net/blog/3e3570d7

背景

目前大环境下，需有效利用现有机器资源来支撑业务应用的数据读写存储；多点现有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可根据实际测试效果适当增大

Placement Rules 使用文档

漫谈TiDB数据库部署

专栏 - TiDB 数据冷热存储分离测试

专栏 - 百TB级TiDB集群在线更换NVME磁盘优化实践 | TiDB 社区