写点什么

TiDB v7.1.0 资源管控功能是如何降低运维难度和成本 - 实现集群资源最大化?

  • 2023-07-07
    北京
  • 本文字数:6354 字

    阅读完需:约 21 分钟

作者: gary 原文来源:https://tidb.net/blog/0e600aaf

一、前言

    在早期听过很多客户一直在讨论TiDB有没有多租户的功能,一直是对标其他分布式数据库的热点话题。TiDB v7.1.0支持基于资源组的资源管控,为同一集群中的不同工作负载分配并隔离资源。该功能显著提升了多应用集群的稳定性,并为多租户奠定了基础。   TiDB 资源管控特性提供了两层资源管理能力,包括在 TiDB 层的流控能力和 TiKV 层的优先级调度的能力。将用户绑定到某个资源组后,TiDB 层会根据用户所绑定资源组设定的配额对用户的读写请求做流控,TiKV 层会根据配额映射的优先级来对请求做调度。通过流控和调度这两层控制,可以实现用户、会话、语句级别的应用资源隔离,满足服务质量 (QoS) 要求。
复制代码

二、资源管控流程图

三、资源管控 (Resource Control) 测试

1)测试集群环境

[tidb@tidb80 tidb]$ tiup cluster display tidb-test     tiup is checking updates for component cluster ...Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.2/tiup-cluster display tidb-testCluster type:       tidbCluster name:       tidb-testCluster version:    v7.1.0Deploy user:        tidbSSH type:           builtinDashboard URL:      http://192.168.2.81:2379/dashboardGrafana URL:        http://192.168.2.80:3000ID                  Role          Host          Ports        OS/Arch       Status   Data Dir                           Deploy Dir--                  ----          ----          -----        -------       ------   --------                           ----------192.168.2.80:9093   alertmanager  192.168.2.80  9093/9094    linux/x86_64  Up       /data/tidb-data/alertmanager-9093  /data/tidb-deploy/alertmanager-9093192.168.2.80:3000   grafana       192.168.2.80  3000         linux/x86_64  Up       -                                  /data/tidb-deploy/grafana-3000192.168.2.81:2379   pd            192.168.2.81  2379/2380    linux/x86_64  Up|L|UI  /data/tidb-data/pd-2379            /data/tidb-deploy/pd-2379192.168.2.82:2379   pd            192.168.2.82  2379/2380    linux/x86_64  Up       /data/tidb-data/pd-2379            /data/tidb-deploy/pd-2379192.168.2.83:2379   pd            192.168.2.83  2379/2380    linux/x86_64  Up       /data/tidb-data/pd-2379            /data/tidb-deploy/pd-2379192.168.2.80:9090   prometheus    192.168.2.80  9090/12020   linux/x86_64  Up       /data/tidb-data/prometheus-9090    /data/tidb-deploy/prometheus-9090192.168.2.80:4000   tidb          192.168.2.80  4000/10080   linux/x86_64  Up       -                                  /data/tidb-deploy/tidb-4000192.168.2.81:20160  tikv          192.168.2.81  20160/20180  linux/x86_64  Up       /data/tidb-data/tikv-20160         /data/tidb-deploy/tikv-20160192.168.2.82:20160  tikv          192.168.2.82  20160/20180  linux/x86_64  Up       /data/tidb-data/tikv-20160         /data/tidb-deploy/tikv-20160192.168.2.83:20160  tikv          192.168.2.83  20160/20180  linux/x86_64  Up       /data/tidb-data/tikv-20160         /data/tidb-deploy/tikv-20160Total nodes: 10
复制代码

2)Request Unit (RU) 概念

3)资源管控参数

此次测试参数如下:



TiDB 流控和 TiKV 调度可以单独管控,组合效果见下图:


4)评估实际负载所需容量

注意事项:评估窗口范围为 10 分钟至 24 小时,TiDB 与 TiKV 的 CPU 利用率不能过低,否则无法进行容量估算。权限:TiDB 与 TiKV 的 CPU 利用率不能过低,否则无法进行容量估算
复制代码


4.1 根据实际负载估算容量

方法一

指定初始时间 START_TIME 和时间窗口 DURATION 大小,根据实际负载查看 RU 容量。


MySQL [(none)]> CALIBRATE RESOURCE START_TIME '2023-06-26 17:25:00' DURATION '10m';  +-------+| QUOTA |+-------+| 14129 |+-------+1 row in set (0.20 sec)
复制代码

or:

指定初始时间 START_TIME 和结束时间 END_TIME,根据实际负载查看 RU 容量。


MySQL [(none)]> CALIBRATE RESOURCE START_TIME '2023-06-26 17:25:00' END_TIME '2023-06-26 17:35:00';+-------+| QUOTA |+-------+| 14129 |+-------+1 row in set (0.53 sec)
复制代码

方法二

4.2 基于硬件部署估算容量

方法一

指定 WORKLOAD 查看 RU 容量


MySQL [(none)]> CALIBRATE RESOURCE;+-------+| QUOTA |+-------+|  9690 |+-------+1 row in set (0.21 sec)
MySQL [(none)]> CALIBRATE RESOURCE WORKLOAD OLTP_WRITE_ONLY;+-------+| QUOTA |+-------+| 9148 |+-------+1 row in set (0.36 sec)
MySQL [(none)]> CALIBRATE RESOURCE WORKLOAD OLTP_READ_ONLY; +-------+| QUOTA |+-------+| 1746 |+-------+1 row in set (0.23 sec)

MySQL [(none)]> CALIBRATE RESOURCE WORKLOAD OLTP_READ_WRITE;+-------+| QUOTA |+-------+| 3721 |+-------+1 row in set (0.01 sec)
复制代码

方法二

5)创建资源组

1.创建 rg1 资源组用于重要应用,限额是每秒 3000 RU,并且允许这个资源组的应用超额占用资源,设置绝对优先级为 HIGH。MySQL [(none)]> CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 2000 BURSTABLE PRIORITY = HIGH;
2.创建 rg2 资源组,RU 的回填速度是每秒 300 RU。在系统资源充足的时候,不允许这个资源组的应用超额占用资源,设置绝对优先级为 LOW。MySQL [(none)]> CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 200 PRIORITY = HIGH;

3.创建 rg3 资源组,RU 的回填速度是每秒 300 RU。在系统资源充足的时候,不允许这个资源组的应用超额占用资源,设置绝对优先级为 MEDIUM。MySQL [(none)]> CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 500 PRIORITY = LOW;

4.创建 rg4 资源组,RU 的回填速度是每秒 300 RU。在系统资源充足的时候,不允许这个资源组的应用超额占用资源,设置绝对优先级为 MEDIUM。MySQL [(none)]> CREATE RESOURCE GROUP IF NOT EXISTS rg4 RU_PER_SEC = 1000 PRIORITY = MEDIUM;

5.展示所有资源组 (resource group) 的信息MySQL [(none)]> SELECT * FROM information_schema.resource_groups; +---------+------------+----------+-----------+| NAME | RU_PER_SEC | PRIORITY | BURSTABLE |+---------+------------+----------+-----------+| default | UNLIMITED | MEDIUM | YES || rg1 | 2000 | HIGH | YES || rg2 | 200 | HIGH | NO || rg3 | 500 | LOW | NO || rg4 | 1000 | MEDIUM | NO |+---------+------------+----------+-----------+5 rows in set (0.01 sec)
复制代码

6)绑定资源组

TiDB 支持如下三个级别的资源组设置:用户级别:通过 CREATE USER 或 ALTER USER 语句将用户绑定到特定的资源组。会话级别:通过 SET RESOURCE GROUP 设置当前会话使用的资源组。语句级别:当集群遇到突发的 SQL 性能问题,可以Optimizer Hint 设置当前语句使用的资源组,临时限制某个 SQL 的资源消耗。
复制代码

6.1 将用户绑定到资源组


MySQL [(none)]> CREATE USER 'test1'@'%' IDENTIFIED BY 'test1' RESOURCE GROUP rg1;Query OK, 0 rows affected (0.09 sec)
MySQL [(none)]> CREATE USER 'test2'@'%' IDENTIFIED BY 'test2' RESOURCE GROUP rg2;Query OK, 0 rows affected (0.04 sec)
MySQL [(none)]> CREATE USER 'test3'@'%' IDENTIFIED BY 'test3' RESOURCE GROUP rg3;Query OK, 0 rows affected (0.06 sec)
MySQL [(none)]> CREATE USER 'test4'@'%' IDENTIFIED BY 'test4' RESOURCE GROUP rg4;Query OK, 0 rows affected (0.04 sec)
MySQL [(none)]> grant all privileges on *.* to 'test1'@'%';Query OK, 0 rows affected (0.05 sec)
MySQL [(none)]> grant all privileges on *.* to 'test2'@'%';Query OK, 0 rows affected (0.04 sec)
MySQL [(none)]> grant all privileges on *.* to 'test3'@'%';Query OK, 0 rows affected (0.03 sec)
MySQL [(none)]> grant all privileges on *.* to 'test4'@'%';Query OK, 0 rows affected (0.03 sec)
MySQL [(none)]> select user,host,User_attributes from mysql.user;+-------+------+---------------------------+| user | host | User_attributes |+-------+------+---------------------------+| root | % | NULL || test1 | % | {"resource_group": "rg1"} || test2 | % | {"resource_group": "rg2"} || test3 | % | {"resource_group": "rg3"} || test4 | % | {"resource_group": "rg4"} |+-------+------+---------------------------+5 rows in set (0.02 sec)
复制代码


Sysbench 压测测试


[tidb@tidb80 tidb]$ cat config_test1mysql-host=192.168.2.80mysql-port=4000mysql-user=test1mysql-password=test1mysql-db=sbtesttime=60threads=16report-interval=10db-driver=mysql
[tidb@tidb80 tidb]$ cat config_test2mysql-host=192.168.2.80mysql-port=4000mysql-user=test2mysql-password=test2mysql-db=sbtesttime=60threads=16report-interval=10db-driver=mysql
[tidb@tidb80 tidb]$ cat config_test3mysql-host=192.168.2.80mysql-port=4000mysql-user=test3mysql-password=test3mysql-db=sbtesttime=60threads=16report-interval=10db-driver=mysql
[tidb@tidb80 tidb]$ cat config_test4mysql-host=192.168.2.80mysql-port=4000mysql-user=test4mysql-password=test4mysql-db=sbtesttime=60threads=16report-interval=10db-driver=mysql
[tidb@tidb80 tidb]$ sysbench --config-file=/tidb/config_test1 /tidb/sysbench/share/sysbench/oltp_write_only.lua --tables=1 --table-size=10000000 --time=600 --mysql-db=rc1 run [tidb@tidb80 tidb]$ sysbench --config-file=/tidb/config_test2 /tidb/sysbench/share/sysbench/oltp_write_only.lua --tables=1 --table-size=2000000 --time=600 --mysql-db=rc2 run[tidb@tidb80 tidb]$ sysbench --config-file=/tidb/config_test3 /tidb/sysbench/share/sysbench/oltp_write_only.lua --tables=1 --table-size=5000000 --time=600 --mysql-db=rc3 run[tidb@tidb80 tidb]$ sysbench --config-file=/tidb/config_test4 /tidb/sysbench/share/sysbench/oltp_write_only.lua --tables=1 --table-size=10000000 --time=600 --mysql-db=rc4 run
复制代码


由于 rg1 设置了应用超额占用资源,rg1 消耗 RU 可达到 2K 以上,由于 rg2,rg3,rg4 没有设置超额分配,就算在系统资源充足,也不会让这个资源组的应用超额占用资源。当系统资源超过限制时,TiDB 会优先满足高优先级 (PRIORITY) 资源组的请求。如果同一优先级的请求无法全部满足,TiDB 会根据用量 (RU_PER_SEC) 的大小按比例分配。


6.2 将当前会话绑定到资源组

通过把当前会话绑定到资源组,会话对资源的占用会受到指定用量 (RU) 的限制。


分别打开 4 个会话绑定不同的资源组,由于 rg1 设置了应用超额占用资源,rg1 消耗 RU 可达到 8K 以上,由于 rg2,rg3,rg4 没有设置超额分配,在限制的 RU 内运行。






6.3 将语句绑定到资源组

当集群遇到突发的 SQL 性能问题,可以结合 SQL Binding 和资源组,临时限制某个 SQL 的资源消耗


将 rg2 资源组设置 ru 为 1 进行语句限制测试,可将某条资源消耗高的语句进行临时限制,从而让集群正常运行


MySQL [(none)]> alter RESOURCE GROUP rg2 RU_PER_SEC = 1;                   

MySQL [(none)]> SELECT * FROM information_schema.resource_groups; +---------+------------+----------+-----------+| NAME | RU_PER_SEC | PRIORITY | BURSTABLE |+---------+------------+----------+-----------+| default | UNLIMITED | MEDIUM | YES || rg1 | 2000 | HIGH | YES || rg2 | 1 | MEDIUM | NO || rg3 | 500 | LOW | NO || rg4 | 1000 | MEDIUM | NO |+---------+------------+----------+-----------+
MySQL [(none)]> select count(*) from rc1.sbtest1 where pad like '%22%'; +----------+| count(*) |+----------+| 3713861 |+----------+
create GLOBAL binding for select count(*) from rc1.sbtest1 where pad like '%22%' using select /*+ RESOURCE_GROUP(small_rg1) */ count(*) from rc1.sbtest1 where pad like '%22%';
MySQL [(none)]> show global bindings;+--------------------------------------------------------------+--------------------------------------------------------------+------------+---------+-------------------------+-------------------------+---------+-----------------+--------+------------------------------------------------------------------+-------------+| Original_sql | Bind_sql | Default_db | Status | Create_time | Update_time | Charset | Collation | Source | Sql_digest | Plan_digest |+--------------------------------------------------------------+--------------------------------------------------------------+------------+---------+-------------------------+-------------------------+---------+-----------------+--------+------------------------------------------------------------------+-------------+| select count ( ? ) from `rc1` . `sbtest1` where `pad` like ? | SELECT count(1) FROM `rc1`.`sbtest1` WHERE `pad` LIKE '%22%' | | enabled | 2023-07-03 11:49:48.436 | 2023-07-03 11:49:48.436 | utf8 | utf8_general_ci | manual | e2231bf96e1696343b39b1897a118cdef02f8d12a651b067b14c887c2611fcfe | |+--------------------------------------------------------------+--------------------------------------------------------------+------------+---------+-------------------------+-------------------------+---------+-----------------+--------+------------------------------------------------------------------+-------------+
MySQL [(none)]> select count(*) from rc1.sbtest1 where pad like '%22%';ERROR 8252 (HY000): Exceeded resource group quota limitation
复制代码

四、总结

1)资源管控特性的引入对 TiDB 具有里程碑的意义,它能够将一个分布式数据库集群划分成多个逻辑单元,利用该特性可以让 TiDB 应对更多的应用场景。2) 可以将多个来自不同系统的中小型应用合入一个 TiDB ,应用透明无侵入对集群资源最大化使用。3)减少了集群数量,降低运维难度及管理成本。


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

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

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

评论

发布
暂无评论
TiDB v7.1.0 资源管控功能是如何降低运维难度和成本-实现集群资源最大化?_实践案例_TiDB 社区干货传送门_InfoQ写作社区