一、前言

在早期听过很多客户一直在讨论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-test Cluster type: tidb Cluster name: tidb-test Cluster version: v7.1.0 Deploy user: tidb SSH type: builtin Dashboard URL: http://192.168.2.81:2379/dashboard Grafana URL: http://192.168.2.80:3000 ID 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-9093 192.168.2.80:3000 grafana 192.168.2.80 3000 linux/x86_64 Up - /data/tidb-deploy/grafana-3000 192.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-2379 192.168.2.82:2379 pd 192.168.2.82 2379/2380 linux/x86_64 Up /data/tidb-data/pd-2379 /data/tidb-deploy/pd-2379 192.168.2.83:2379 pd 192.168.2.83 2379/2380 linux/x86_64 Up /data/tidb-data/pd-2379 /data/tidb-deploy/pd-2379 192.168.2.80:9090 prometheus 192.168.2.80 9090/12020 linux/x86_64 Up /data/tidb-data/prometheus-9090 /data/tidb-deploy/prometheus-9090 192.168.2.80:4000 tidb 192.168.2.80 4000/10080 linux/x86_64 Up - /data/tidb-deploy/tidb-4000 192.168.2.81:20160 tikv 192.168.2.81 20160/20180 linux/x86_64 Up /data/tidb-data/tikv-20160 /data/tidb-deploy/tikv-20160 192.168.2.82:20160 tikv 192.168.2.82 20160/20180 linux/x86_64 Up /data/tidb-data/tikv-20160 /data/tidb-deploy/tikv-20160 192.168.2.83:20160 tikv 192.168.2.83 20160/20180 linux/x86_64 Up /data/tidb-data/tikv-20160 /data/tidb-deploy/tikv-20160 Total 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_test1 mysql-host=192.168.2.80 mysql-port=4000 mysql-user=test1 mysql-password=test1 mysql-db=sbtest time=60 threads=16 report-interval=10 db-driver=mysql [tidb@tidb80 tidb]$ cat config_test2 mysql-host=192.168.2.80 mysql-port=4000 mysql-user=test2 mysql-password=test2 mysql-db=sbtest time=60 threads=16 report-interval=10 db-driver=mysql [tidb@tidb80 tidb]$ cat config_test3 mysql-host=192.168.2.80 mysql-port=4000 mysql-user=test3 mysql-password=test3 mysql-db=sbtest time=60 threads=16 report-interval=10 db-driver=mysql [tidb@tidb80 tidb]$ cat config_test4 mysql-host=192.168.2.80 mysql-port=4000 mysql-user=test4 mysql-password=test4 mysql-db=sbtest time=60 threads=16 report-interval=10 db-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 | +--------------------------------------------------------------+--------------------------------------------------------------+------------+---------+-------------------------+-------------------------+---------+-------------`rc1` . `sbtest1` where `pad``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）减少了集群数量，降低运维难度及管理成本。