写点什么

TiDB 落地 SAS 机器实践

  • 2023-06-02
    北京
  • 本文字数:5981 字

    阅读完需:约 20 分钟

作者: 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(分片)找运维支持单独格式化了台机器


部署方案

  • 每台机器 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 分钟表现均符合预期




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 查询延迟




单独备份部分表还原到 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 社区


发布于: 刚刚阅读数: 3
用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB 落地SAS机器实践_实践案例_TiDB 社区干货传送门_InfoQ写作社区