TiDB 7.1.0 LTS was released some time ago. I believe many students have already used it first, and it has even been pushed to the production environment after a series of verifications. Facing several important features of TiDB 7.1, the new GA's Resource Control is a heavyweight feature that must be fully understood and tested. For me, who has been working hard in a front-line DBA position for many years, I have been unable to improve academically. Most of my time is spent on strengthening the "technical" aspects, so I must follow every TiDB update (new), and every new GA feature must be updated. Be familiar with it, so that when the production environment TiDB is upgraded to the target version, you will not be in a hurry. Only after you create a new TiDB cluster can you become familiar with the new features. I believe this article will bring some substantial gains to readers. Closer to home, this article will focus on the theme of "resource management and control" and explain in detail 6 things you should know about "resource management and control".
Start from the user scenario and see how to use the features
Standing out from the 200+ domestic databases, its effective and complete documents are undoubtedly "indispensable". The usage scenario is described in the TiDB 7.1 documentation as follows:
The introduction of resource management and control features is a milestone for TiDB. It can divide a distributed database cluster into multiple logical units. Even if individual units overuse resources, they will not crowd out the resources required by other units. Take advantage of this feature:
○ You can combine multiple small and medium-sized applications from different systems into a TiDB cluster. Increased load on individual applications will not affect the normal operation of other businesses. When the system load is low, even if a busy application exceeds the set read and write quota, it can still be allocated the required system resources to maximize resource utilization.
○ You can choose to combine all test environments into a cluster, or organize large batch tasks into a separate resource group to ensure that important applications obtain necessary resources while improving hardware utilization and reducing operating costs.
○ When there are multiple business loads in the system, different loads can be placed into their own resource groups. Use resource management and control technology to ensure that the response time of transactional business is not affected by data analysis or batch business.
○ When the cluster encounters sudden SQL performance problems, you can combine SQL Binding and resource groups to temporarily limit the resource consumption of a certain SQL.
So, looking at this passage from a pragmatic DBA perspective, it might look like this:
Resource management and control, this new feature, quantifies the performance indicators of daily behaviors such as users, sessions, and SQL in the database in a more detailed manner. The quantitative concept of "Request Unit (RU)" has been introduced, which currently includes three important indicators: CPU, IOPS, and IO bandwidth. In the future, indicators such as memory and network will be added.
○ Several MySQL databases can be merged into a TiDB cluster, such as the OA system where the read and write peaks often occur during the day, the Batch system where the read and write peaks often occur at night, and the data collection system that runs 24 hours a day but has a stable load. This "three-in-one" approach allows each system to "shift peak travel" and use resource management and control capabilities to "allocate on demand" to achieve the goal of reducing overall costs.
○ In a TiDB cluster, create different test users (User) for different test environments (Env), then create different resource groups (Resource Group) based on the resource specifications required for testing, and bind the users to the corresponding resource groups. This achieves resource isolation for different users. Since it is a test environment, the resource group can be set to BURSTABLE , or it can be understood as "oversold". The resources used by one or several users exceed the limits specified by the resource group. It can still be used normally without affecting the test, and can maximize the use of hardware resources. However, the test here should be understood as a business test rather than a standard performance test. Otherwise, resource allocation and the use of over-limit (BURSTABLE) need to be considered more rigorously .
○ Similar to the description in Section 1, the three systems correspond to three resource groups respectively, and BURSTABLE is set to NO, then the resources used by the three systems will be isolated and not affected by each other. That is to say, in the current TiDB cluster, even if the TP and AP services are running at the same time, due to the use of the resource control feature, the TP service will not be interfered by the AP service at this time.
○ Business is constantly changing, and "Bad SQL" problems may occur at any time. If a certain SQL consumes too high resources (RU), it will affect the performance of other SQL for the user. At this time, you can create a new resource group and use the execution plan binding (SQL Binding) function to bind the SQL statement to the newly created resource group to limit SQL resource consumption or even refuse SQL execution. The test SQL is as follows:
CREATE RESOURCE GROUP rg1 RU_per_SEC=1;
CREATE GLOBAL BINDING FOR
SELECT COUNT(*) FROM t1 t JOIN t1 t2 USING (uid)
USING
SELECT /*+ resource_group(rg1) */ COUNT(*) FROM t1 t JOIN t1 t2 USING (uid);
EXPLAIN ANALYZE FORMAT = 'verbose' SELECT COUNT(*) FROM t t1 JOIN t1 t2 USING (uid);In order to realize the above scenario, TiDB implements several SQL syntaxes. Let’s take a look at how to operate them.
"Resource control" related SQL, these are enough
Are there any people who study TiDB who don’t know AskTUG [1] ? Half a year ago, @Community Assistant compiled a post of great practical value - [Community Wisdom Collection] TiDB-related SQL scripts[2] , which contains 38 practical SQLs and is one of the posts that TiDBers must collect.
At that time, the "resource control" function had not yet "come out", so the post did not include the SQL related to this feature. Below I will post the essence of the "resource control" related SQL for reference.
1) Add, delete, modify and check -- Resource Group
- increase:
-- 创建 `rg1` 资源组，限额是每秒 `500 RU`，优先级为 `HIGH`，允许这个资源组的超额 (`BURSTABLE`) 占用资源。
CREATE RESOURCE GROUP IF NOT EXISTS rg1
RU_PER_SEC = 100
PRIORITY = HIGH
BURSTABLE;
-- 创建 `rg2` 资源组，限额是每秒 `500 RU`，其他选项为默认值。
CREATE RESOURCE GROUP rg2 RU_PER_SEC = 200;- delete:
-- 删除资源组
DROP RESOURCE GROUP rg2;- change:
-- 修改资源组资源配置
ALTER RESOURCE GROUP rg2 ru_per_sec = 2000;- check:
-- 通过 I_S 表查看
SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS;It should be noted that to create, modify, and delete resource groups, you need to have SUPER or RESOURCE_GROUP_ADMIN permissions, otherwise you will encounter errors:
ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or RESOURCE_GROUP_ADMIN privilege(s) for this operation2) Bind users to Resource Group
- Bind a user to a resource group
Binding a user to a resource group is very simple. In fact, it means modifying the user's attributes. If it is an already created user, you can use ALTER USER. If it is a new user, you can use CREATE USER.
-- CREATE
CREATE USER u3 RESOURCE GROUP rg3;
-- ALTER
ALTER USER u2 RESOURCE GROUP rg2;- View a user bound to a resource group
There are two methods and two questions here. The two methods are to query through the mysql library and the INFORMATION_SCHEMA library respectively.
mysql> SELECT User, JSON_EXTRACT(User_attributes, "$.resource_group") AS RG FROM mysql.user ;
+------+-----------+
| User | RG |
+------+-----------+
| root | NULL |
| u1 | "default" |
| u2 | "rg2" |
| u3 | "" |
+------+-----------+
4 rows in set (0.00 sec)Question 1: Resource Group ** is the same as default**
Judging from the above query results, except for the resource group rg2 bound to the ordinary user u2, the other three users actually use the default resource group, which is default. It's just that there is an empty space (``) here, which may cause some doubts. After confirming with the official classmates, "the empty space and default are the same in terms of behavior . " For communication posts, see: resource control, default resource group document errata [3]
Question 2: The user-bound resource group cannot be queried through INFORMATION_SCHEMA.USER_ATTRIBUTES .
Ordinary users do not have the right to query which users are bound to which resource groups through the mysql library, including the current user, but each user can query the information they should be able to obtain through the I_S library. Therefore, method two means that ordinary users obtain relevant information by querying the I_S library. The SQL is as follows:
SELECT * FROM INFORMATION_SCHEMA.USER_ATTRIBUTES;It's just that the current effect is not satisfactory, and I hope it will be improved in the next version. For related posts, see: resource control related, INFORMATION_SCHEMA.USER_ATTRIBUTES table value problem[4]
3) Bind the session to Resource Group
Binding users to RG was mentioned earlier. In fact, TiDB provides a more flexible way to bind sessions to RG and bind SQL statements to RG.
- Bind the current session to a resource group
SET RESOURCE GROUP rg1;- View the resource groups used by the current session
SELECT CURRENT_RESOURCE_GROUP();- Reset the current session bound resource group
SET RESOURCE GROUP `default`;
SET RESOURCE GROUP ``;Note: The functions of the two SQLs are equivalent, but it is recommended to use the first one. For the reason, see [Question 1].
4) Bind statements to Resource Group
You can use Hint to control the RU resources occupied by a specific SQL statement, for example:
SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t1 limit 10;How to check the RU consumed by a certain statement? It can be obtained through the actual execution plan, for example:
EXPLAIN ANALYZE SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t1 limit 10;
5) The indispensable PROCESSLIST
INFORMATION_SCHEMA is a set of read-only views defined in the ANSI standard that provides information about all tables, views, columns, and procedures in the database. Multiple relational databases have their own implementations. In the INFORMATION_SCHEMA.PROCESSLIST table of TiDB, the field RESOURCE_GROUP varchar(32) is added to display which resource group is used by the current active session.
The case is as follows: open three windows and start three sessions, using the default resource group, session-level resource group, and statement-level resource group respectively:
mysql -h 192.168.195.128 -P 4000 -c -u u1 -e 'select sleep(1000)'
mysql -h 192.168.195.128 -P 4000 -c -u u2 -e 'SET RESOURCE GROUP `rg1`; select sleep(1000)'
mysql -h 192.168.195.128 -P 4000 -c -u u3 -e 'SELECT /*+ RESOURCE_GROUP(rg1) */ * sleep(1000)'At this time, use the root user to view the INFORMATION_SCHEMA.PROCESSLIST table:
mysql> SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER;
+------+----------------+-------------------------------------------------------------------------------------+
| USER | RESOURCE_GROUP | INFO |
+------+----------------+-------------------------------------------------------------------------------------+
| root | default | SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER |
| u1 | default | select sleep(1000) |
| u2 | rg1 | select sleep(1000) |
| u3 | rg1 | SELECT /*+ RESOURCE_GROUP(rg1) */ sleep(1000) |
+------+----------------+-------------------------------------------------------------------------------------+
4 rows in set (0.00 sec)
See the related discussion here (thanks to @db_user for the tip): resource control, how to view session level variables[5]
Question 3: I_S.USER_ATTRIBUTES / I_S.RESOURCE_GROUPS permission control
Continuing from the above example, if an ordinary user, such as user u2, views the INFORMATION_SCHEMA.PROCESSLIST table, only the current user, or the information that can be seen within the scope of authority, will be displayed:
mysql> SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER;
+------+----------------+-------------------------------------------------------------------------------------+
| USER | RESOURCE_GROUP | INFO |
+------+----------------+-------------------------------------------------------------------------------------+
| u2 | rg2 | SELECT USER, RESOURCE_GROUP, INFO from INFORMATION_SCHEMA.PROCESSLIST ORDER BY USER |
| u2 | rg1 | select sleep(1000) |
+------+----------------+-------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
The inference here is that PROCESSLIST is an existing table, and the permission settings are based on the previous logic. Only fields are added here, so permission isolation is well inherited, that is, ordinary users have no rights and cannot see other users, such as users. The resource group in use by u1.
However, such fine-grained permission control is not implemented for the newly added tables INFORMATION_SCHEMA.USER_ATTRIBUTES and INFORMATION_SCHEMA.RESOURCE_GROUPS.
○ For the table USER_ATTRIBUTES, ordinary users can view the attributes of all users. If the function of [Question 2] is implemented, then ordinary users can view the resource groups bound to all users.
○ For table RESOURCE_GROUPS, ordinary users can view all resource groups. So, regarding the Bad SQL problem, there is actually another way to deal with it. Developers can write Hint in SQL, so that Bad SQL can "override authority" to call the default resource group, which may break the balance and affect other business performance, or more serious. Break through resource planning and reproduce the power of "a single SQL bombards the entire TiDB cluster".
From a permission perspective, although different resource groups controlled by resource management and control achieve resource isolation, ordinary users can switch resource groups at the Session level at will. For example, the administrator binds ordinary user u2 to resource group rg1, but u2 logs in to TiDB. After that, you can switch to rg2 to obtain the usage rights of the resource group that is allocated more resources.
Related communication post links: resource control, I_S permission control issues[6]
As I mentioned in my post, for TiDB, efficient and quality-guaranteed implementation of functions is the first priority, followed by the implementation of privileges (Privileges). This is acceptable and understandable. After all, in such a market environment with such involution and fierce competition among domestic databases, "survival" is the top priority. But Rule is Rule, and permissions (which can be extended to "security") are also a very important topic that cannot be avoided.
6) Resource Control related configuration items
See the official document [7] , two new variables introduced by resource management and control,
TiDB: Control whether to turn on resource group flow control by configuring the global variable tidb_enable_resource_control.
TiKV: Use the configuration parameter resource-control.enabled to control whether to use request scheduling based on resource group quotas.
Here’s how to view it:
-- tidb
SHOW VARIABLES LIKE "tidb_enable_resource_control";
-- tikv
SHOW CONFIG WHERE NAME LIKE "resource-control.enabled";7) Calibrate resource estimation
According to the document Estimating Cluster Capacity [8] , there are currently two estimation methods: estimating capacity based on actual load and estimating capacity based on hardware deployment. The more intuitive method is estimating capacity based on hardware deployment, which is specifically named as follows:
-- 默认 TPC-C 模型预测，等同于下一条命令
CALIBRATE RESOURCE;
-- 根据类似 TPC-C 的负载模型预测
CALIBRATE RESOURCE WORKLOAD TPCC;
-- 根据类似 sysbench oltp_write_only 的负载模型预测
CALIBRATE RESOURCE WORKLOAD OLTP_WRITE_ONLY;
-- 根据类似 sysbench oltp_read_write 的负载模型预测
CALIBRATE RESOURCE WORKLOAD OLTP_READ_WRITE;
-- 根据类似 sysbench oltp_read_only 的负载模型预测
CALIBRATE RESOURCE WORKLOAD OLTP_READ_ONLY;On the TiDB Dashboard v7.1.0 panel, we can see that the [Resource Management and Control] menu has been added, as shown in the figure,
You can also check the resource estimation here, but in fact, Dashboard also calls the above SQL to make predictions, which can be confirmed from the TiDB-Server log.
...[INFO] [session.go:3878] ... [sql="calibrate resource workload tpcc"]
...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_read_write"]
...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_read_write"]
...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_read_only"]
...[INFO] [session.go:3878] ... [sql="calibrate resource workload oltp_write_only"]In addition, this estimation model is an algorithm implemented based on TiDB's years of experience and benchmark testing, and is suitable for a variety of environments. By extension, how should we deal with clusters that have not been upgraded to TiDB v7.1.0, or that need to estimate the capacity of the database that will be synchronized to the TiDB cluster? The calculation process is slightly complicated. If you are interested, you can refer to the relevant source code calibrate_resource [9] .
“Resource management and control” also requires monitoring
1) TiDB Dashboard
As mentioned above, TiDB Dashboard has added a [Resource Management and Control] [10] menu. In the lower part of the page, RU related charts are displayed. You can view the RU load status of the TiDB cluster at a glance, and you can also select a certain time period in the chart. , to use the “capacity estimation based on actual load” [11] function.
2) Grafana
Compared with TiDB Dashboad, Grafana provides more comprehensive monitoring data, and even displays read RU (RRU) and write RU (WRU) separately on the panel. There are few conceptual descriptions of RRU/WRU, which are only reflected in the Token Buckets chapter of the design document [12] and the parameter introduction page of Grafana.
Question 4: RRU/WRU expression problem
Regarding the expression of RRU/WRU, in fact, just pay attention to RU. This is the predicted value after benchmark testing and has a unified observation value. It is only distinguished on the monitoring panel to observe the read and write status of the TiDB cluster. In the code In the submitted records, there are also comments from R&D students, "It is RU for users, and there are more details in the monitoring items." For related communication posts, see:
- resource control, Grafana panel default configuration[13]
- resource control, Grafana document content is incomplete[14]
3) RU margin problem
For daily operation and maintenance, there are at least two monitoring indicators that need to be considered:
○ Daily RU balance monitoring
○ Abnormal RU sudden increase monitoring
Among them, for RU balance monitoring, TiDB 7.1 can only see the RU usage from the Grafana panel, and does not directly display the RU balance situation, so it has been enhanced in TiDB 7.2. For specific implementation, please refer to PR: resource_manager: add metrics for available RU #6523 [15] .
Figure--Grafana panel of TiDB 7.1
Figure--Grafana panel of TiDB 7.2
4) Log
It can be seen from the logs when resource management and control is actually called, but it cannot be seen through the logs or panels which users have used the resource group.
[2023/06/29 11:27:50.069 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [[email protected]] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="select @@version_comment limit 1"]
[2023/06/29 11:27:58.973 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [[email protected]] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="select current_resource_group()"]
[2023/06/29 11:28:09.557 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [[email protected]] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="set resource group rg1"]
[2023/06/29 11:28:19.532 +09:00] [INFO] [session.go:3878] [GENERAL_LOG] [conn=7398943596793037429] [[email protected]] [schemaVersion=53] [txnStartTS=0] [forUpdateTS=0] [isReadConsistency=false] [currentDB=] [isPessimistic=false] [sessionTxnMode=PESSIMISTIC] [sql="select * from test.t1 limit 1"]
[2023/06/29 11:28:19.534 +09:00] [INFO] [controller.go:287] ["[resource group controller] create resource group cost controller"] [name=rg1]If the situation described in [Question 3] does occur and Bad SQL is running "out of authority", you can look for clues from the logs.
TiFlash may support Resource Control in future versions
In the current version (TiDB 7.1.0 LTS), TiFlash does not currently support resource management and control functions, and is expected to be supported in future versions. Let's observe the scheduling of resource management and control by the TiFlash component through two experiments. The result is definitely unused. However, this experiment can be done again after the future version is released. I believe that different results will be obtained.
Experiment 1: Specify SQL to read data from TiFlash and observe the RU value in the execution plan
Create a TiFlash copy of the experimental table t, read data from TiKV/TiFlash respectively, and check the RU value in the actual execution plan.
-- tiflash replica
ALTER TABLE t SET TIFLASH REPLICA 1;
-- read from tiflash
EXPLAIN ANALYZE FORMAT = 'verbose'
SELECT /*+ read_from_storage(tiflash[t]) */ COUNT(*)
FROM t;
-- read from tikv
EXPLAIN ANALYZE FORMAT = 'verbose'
SELECT /*+ read_from_storage(tikv[t]) */ COUNT(*)
FROM t;The SQL execution result is shown in the figure. The RU value of SQL reading data from TiKV is about 40, while the RU value of TiFlash is 0, indicating that the current version of TiFlash does not support RU calculation.
Experiment 2: Observe from the log whether the resource group controller is called
When a user connects to TiDB and issues a SQL statement to TiDB, TiDB Server initiates a request to PD, PD will create (allocate) a resource group controller, and TiDB Server will print relevant information to the log. ,like:
... [INFO] [controller.go:287] ["[resource group controller] create resource group cost controller"] [name=rg1]We can analyze the logs of TiDB Server to observe whether the query sent to TiFlash calls the resource group controller, and use this to determine whether TiFlash implements RU calculation. The controlled tests are as follows:
EXPLAIN ANALYZE FORMAT = 'verbose' SELECT /*+ RESOURCE_GROUP(rg2), read_from_storage(tikv[t]) */ COUNT(*) FROM t;
EXPLAIN ANALYZE FORMAT = 'verbose' SELECT /*+ RESOURCE_GROUP(rg3), read_from_storage(tiflash[t]) */ COUNT(*) FROM t;
From the screenshot, you can intuitively see that the resource controller created a resource group cost controller (resource group cost controller) for the above SQL, and the resource group name is rg2. Since the following SQL reads data from TiFlash, it does not call the resource controller to create a new resource group consumption controller.
It should be noted that continuous triggering of this experiment may not yield the desired results, because the resource group controller instantiation judgment logic is implemented in the source code, that is, in this experiment, if the resource controller has been created for user u2 rg2 resource group, then consecutive sessions will continue to use the already created controller. Only when the GC time exceeds (default 10 minutes) and a new session is initiated again, a new resource group consumption controller will be created again.
Compatibility with MySQL
The article has listed the syntax of resource control in TiDB in detail. There is also Resource Groups [16] feature in MySQL 8.0. For details, please refer to WL#9467: Resource Groups [17] . However, the implementation of TiDB is different. are not compatible.
If you manage TiDB and MySQL at the same time, you need to make more distinctions to avoid confusion when using them.
Similarities
○ The resource group related commands in TiDB and MySQL, "Create (CREATE RESOURCE GROUP) Delete (DROP RESOURCE GROUP) Change (ALTER RESOURCE GROUP) Check (SELECT * FROM INFORMATION_SCHEMA.RESOURCE_GROUPS)" have similar syntax, but the parameters followed by the command are different. The I_S.RESOURCE_GROUPS table structure is also different.
○ TiDB and MySQL both support Hint and can implement statement-level resource group calls.
INSERT /*+ RESOURCE_GROUP(rg1) */ into t1 values (1);the difference
- The thread priority (THREAD_PRIORITY) setting of the resource group in MySQL requires turning on CAP_SYS_NICE in Linux. But TiDB doesn't need it.
[Service]
AmbientCapabilities=CAP_SYS_NICE- The RU set in the resource group in TiDB is a fixed value, while in MySQL you can specify vCPU as a range value. This range value corresponds to all available CPUs.
mysql> select version()\G
*************************** 1. row ***************************
version(): 8.0.28
1 row in set (0.00 sec)
mysql> ALTER RESOURCE GROUP rg1 VCPU = 0-1;
Query OK, 0 rows affected (0.01 sec)- Some SQL syntax or functions (Functions) in TiDB are unique and incompatible with MySQL, such as CURRENT_RESOURCE_GROUP().
Return to the roots and look at cgroup again
As mentioned earlier, MySQL needs to use Nice to control thread priority. In fact, friends who are familiar with Linux systems know that Nice has been famous for a long time, and cgroup, a latecomer, has gradually come into people's field of vision in recent years, especially virtualization and cloud technologies (such as After Docker, Kubernetes) mature, cgroup technology is even more indispensable. For example, starting from RHEL 7, you can directly set CPUAccounting and CPUShares in the systemd file for a certain service to control the CPU usage of the process. Starting from RHEL 8, cgroup v2 has been introduced to improve functions and simplify configuration. The CPU control parameters have also been adjusted and changed to cpu.weight.
For TiDB, cgroups have also been used for a long time [18] , such as controlling the memory quota of the service in the systemd file of TiDB Server to control OOM trigger conditions. In addition, in the TiDB v5.0 version, the implementation logic of the TiDB Server parameter performance.max-procs has been modified and changed to "the number of CPUs of the current machine or cgroups by default". For related content, please refer to PR #17706 [ 19 ] .
Summarize
Due to time constraints, I will share the content about "Resource Control" here for the time being. There is a lot of content. I believe that all "Ti friends" who can read this really love TiDB. The text shares several specific usage methods and raises several questions, striving to be truthful and pragmatic. I believe it will be helpful to TiDBer. Finally, the exploration of Resource Control has just begun, and we look forward to functional enhancements in subsequent versions (for example, downgrading or aborting timeout SQL (already implemented in TiDB 7.2), incorporating more resources such as memory into RU, and allowing users to bind multiple Resource group, etc.), and we also look forward to sharing more production cases about this feature.
References
- AskTUG: https://asktug.com/
- [Collection of community wisdom] A complete collection of TiDB related SQL scripts: https://asktug.com/t/topic/999618
- resource control, default resource group Document errata: https://asktug.com/t/topic/1008372/6?u=shawnyan
- Resource control related, INFORMATION_SCHEMA.USER_ATTRIBUTES table value problem: https://asktug.com/t/topic/1008437
- resource control, how to view session level variables: https://asktug.com/t/topic/1008357
- resource control, I_S permission control issue: https://asktug.com/t/topic/1008596
- Official documentation: https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#%E7%9B%B8%E5%85%B3%E5%8F%82%E6%95%B0
- Estimated cluster capacity: https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#%E9%A2%84%E4%BC%B0%E9%9B%86%E7%BE% A4%E5%AE%B9%E9%87%8F
- calibrate_resource: https://github.com/pingcap/tidb/blob/v7.1.0/executor/calibrate_resource.go#L295
- [Resource Management and Control]: https://docs.pingcap.com/zh/tidb/stable/dashboard-resource-manager
- "Estimate capacity based on actual load": https://docs.pingcap.com/zh/tidb/stable/sql-statement-calibrate-resource#%E6%A0%B9%E6%8D%AE%E5%AE%9E %E9%99%85%E8%B4%9F%E8%BD%BD%E4%BC%B0%E7%AE%97%E5%AE%B9%E9%87%8F
- Design documentation: https://github.com/pingcap/tidb/blob/master/docs/design/2022-11-25-global-resource-control.md#distributed-token-buckets
- resource control, Grafana panel default configuration: https://asktug.com/t/topic/1008464
- resource control, Grafana document content is incomplete: https://asktug.com/t/topic/1008693
- resource_manager: add metrics for avaiable RU #6523: https://github.com/tikv/pd/pull/6523
- Resource Groups: https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html
- WL#9467: Resource Groups: https://dev.mysql.com/worklog/task/?id=9467
- Use case: https://asktug.com/t/topic/37127/2?u=shawnyan
- #17706: https://github.com/pingcap/tidb