In the world of managing clusters, making sure resources are distributed properly is crucial. Without this, some user requests can take up too much of the resources, causing issues for more critical tasks.
To tackle this, we set limits or quotas for various resource groups. The TiDB feature comes in handy here, allowing requests from users to be allocated properly. At the same time, the TiKV layer schedules these requests based on their importance, which is determined by these quotas.
This two-step method ensures that your applications receive the resources they require without causing trouble for others. It’s like keeping things running smoothly and preventing any traffic jams in your cluster.
Use cases for Resource Control
Optimizing Workloads: When you’re dealing with various workloads on different TiDB machines, especially if some of them are smaller or medium-sized, you can consolidate them into a single TiDB cluster for more efficient management.
Team-Focused Clusters: In environments where multiple teams share the same cluster, you can set priorities for each team to ensure smooth collaboration and resource allocation.
Let’s explore an example where multiple teams are sharing a single TiDB cluster, and these teams can be categorized as follows
| Team | Comments | RPS |
|---|---|---|
| ‘Main-Transactions’ | Responsible for main business happening in a cluster | 5000 |
| ‘Report-Queries’ | For scheduled OLAP requests | 500 |
| ‘Adhoc-Requests’ | Manual queries fired by developers | 500 |
RPS - Request Units Per Seconds
Below we can see the details about the resource group we created.
mysql> SELECT * FROM information_schema.resource_groups WHERE NAME IN("main_transaction","report_details","adhoc_details");# +------------------+------------+----------+-----------+-------------+------------+| NAME | RU_PER_SEC | PRIORITY | BURSTABLE | QUERY_LIMIT | BACKGROUND |+------------------+------------+----------+-----------+-------------+------------+| adhoc_details | 500 | MEDIUM | NO | NULL | NULL || main_transaction | 5000 | HIGH | YES | NULL | NULL || report_details | 500 | MEDIUM | YES | NULL | NULL |+------------------+------------+----------+-----------+-------------+------------+3 rows in set (0.48 sec)Note: main_transaction has the highest priority with more RU / sec.
Traffic is generated by sysbench client on the TiDB nodes and with the implementation of resource control were able to see the following metrics,

Breaking down with each individual metrics,
Main Transactions

Reports

Ad-hoc queries

In this scenario, the primary transaction group has the flexibility to utilize resources beyond their allocated limits, effectively making them a high-priority group. Meanwhile, the other groups are considered as having normal priority. The request_details group also has the liberty to exceed its allocated resource limit.
As depicted in the graph, the primary transaction group doesn’t experience downtime thanks to its high-priority status. The other groups share equal priority, so when one group experiences a resource shortage, another group can make use of those resources without disruption.
In summary, TiDB resource control feature empowers you to efficiently manage your clusters and allocate resources as needed. Whether you’re dealing with high-priority tasks or maintaining a seamless workflow for various teams, this solution ensures smooth operations.
If you have any questions or require assistance, feel free to reach out to us at sales@mafiree.com. We’re here to help you make the most of your TiDB cluster management.
Miru IT Park, Vallankumaranvillai,
Nagercoil, Tamilnadu - 629 002.
Unit 303, Vanguard Rise,
5th Main, Konena Agrahara,
Old Airport Road, Bangalore - 560 017.
Call: +91 6383016411
Email: sales@mafiree.com