[TiDB Usage Environment] Poc
[TiDB Version] 7.1
[Reproduction Path] Operations performed that led to the issue
[Encountered Issue: Issue Phenomenon and Impact]
[Resource Configuration] Enter TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachment: Screenshot/Logs/Monitoring]
Normally, an ordinary user can only view the databases and tables they have permission to access.
For example, user u2:
mysql> show create user u2;
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| CREATE USER for u2@% |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| CREATE USER 'u2'@'%' IDENTIFIED WITH 'mysql_native_password' AS '' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK PASSWORD HISTORY DEFAULT PASSWORD REUSE INTERVAL DEFAULT ATTRIBUTE '{"comment": "u2c"}' |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.17 sec)
mysql> SELECT User, JSON_EXTRACT(User_attributes, "$.resource_group") AS RG FROM mysql.user where user = 'u2';
+------+-------+
| User | RG |
+------+-------+
| u2 | "rg2" |
+------+-------+
1 row in set (0.06 sec)
So, if the permissions for resource control features are further refined,
shouldn’t the current user (u2) only be able to see the resource group (rg2) they are bound to and the default resource group (default),
instead of being able to see all resource groups?
$ mysql -h 192.168.195.128 -P 4000 -c -u u2
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 411
Server version: 5.7.25-TiDB-v7.1.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible
Copyright (c) 2000, 2022, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SELECT * FROM information_schema.resource_groups;
+----------------------------------+------------+----------+-----------+
| NAME | RU_PER_SEC | PRIORITY | BURSTABLE |
+----------------------------------+------------+----------+-----------+
| default | UNLIMITED | MEDIUM | YES |
xxx
| rg2 | 2 | MEDIUM | NO |
xxx
+----------------------------------+------------+----------+-----------+
7 rows in set (0.06 sec)
It is probably because it is now allowed to modify the resource group from the session level/statement level.
If a user can only see their own resource group and the default resource group, then they can only modify the resource group within these two groups.
Moreover, changing to the default resource group means no resource control, which is also quite strange.
Essentially, there are two prominent issues now:
No distinction between read and write. In most systems, TiDB and TiKV can be independently scaled, and the read and write RU of each TiDB cluster are unbalanced. If the RU limit is set reasonably for writing, it may be unreasonable in reading scenarios (exceeding/not enough). In mixed load scenarios, to maintain cluster stability, you can only take the minimum value of both read and write. This may be the essential reason for switching resource groups at the session level/statement level.
Cannot be set as a percentage. The number of read and write RUs in a TiDB cluster can dynamically change with scaling in/out. Without percentage settings, after scaling in/out, all resources need to be re-estimated and set according to the RU after scaling. With many resource groups, it is very frustrating.
Even though the documentation has this sentence:
1. What happens when the total usage (RU_PER_SEC) set by each resource group exceeds the system capacity? TiDB does not check capacity when creating resource groups. As long as the system has enough idle resources, TiDB will meet the usage settings of each resource group. When system resources exceed the limit, TiDB will prioritize requests from high-priority (PRIORITY) resource groups. If requests of the same priority cannot all be met, TiDB will allocate proportionally based on usage (RU_PER_SEC).
It can only be said that there is no need to reset in the scenario of scaling in. In the scenario of scaling out, the resource group settings still need to be changed again.
However, overall, if your resources are very tight, like my poor version of a 4c8g cluster, resource control can still significantly improve the stability of the entire cluster. The flaws do not overshadow the virtues.
It’s a bit off-topic, haha. What I was actually talking about is the issue of permissions. Right now, it’s not detailed enough, but functionality comes first, which is understandable.
As for the two issues you mentioned:
It actually also involves read and write, that’s where wru/rru comes from. As for statement-level, it’s mainly to solve the bad SQL problem. DBAs can set bindings to directly suppress the SQL sent by the app.
The percentage thing is very hard to control. The percentage also needs to be translated into specific RUs. As for the cause of crashes, TiDB’s white screen is indeed a shortcoming. If this aspect is strengthened, it won’t crash.
Or let me put it another way, for this user, regardless of the reason, they just want to switch from the 600ru group to the 400ru group. Both groups exist. But currently, they are by default a user of the 600ru group.
If they can only see the 600ru and the default resource group,
how should they switch?
If they can’t see all the resource groups (and can’t see this 400ru), but can switch to it, that would be very strange.
So I understand that in this situation, seeing all resource groups might be unavoidable.
In my opinion, it’s not strange. I also wrote it in the article, just didn’t reflect it in a specific post. In my view, it’s an issue caused by missing permissions.
My thoughts might be relatively superficial. After all, I’m not a professional DBA.
Your article might not be out yet, so I’ll check it out when it is.
I guess it should be a many-to-many relationship between resource groups and users to control permissions.
This is indeed better than the current situation.
|
username: ShawnYan
|
username: 
|
username: