resource control, I_S 权限控制问题

【 TiDB 使用环境】Poc
【 TiDB 版本】 7.1
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】

正常来说,一个普通用户只能查看到自己有权限查看的库表,

比如 用户 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)

那么, 如果资源控制特性的权限加以细化,
是不是也应该只能看到当前用户(u2)
被绑定的资源组(rg2)和默认资源组(default),
而不是全部资源组都能看见?

$ 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)

https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#将当前会话绑定到资源组

估计是因为现在是允许你从会话级/语句级修改资源组的。
如果一个用户只能看到自己所在的资源组和默认资源组,那他就只能在这两个组里面修改资源组。
而且改到默认资源等于没有资源管控,这也很奇怪吧。 :joy:

从本质上来说,现在ru有两个突出的问题:
1,不分读写。大部分系统tidb,tikv可以独立扩展,每个tidb集群的读写ru都是不平衡的。如果为写设置ru限制合理,那么在读的场景下可能就是不太合理的(超过/不够)。混合负载的场景下要保持集群稳定,只能取读写2者的最小值。
这可能是需要在会话级/语句级切换资源组的本质原因。

2,不能按照百分比设置,tidb集群的读写ru数量是可以随着缩容/扩容,动态变化的, 没有百分比设置,则导致缩容/扩容后,要把所有的资源根据缩容/扩容后的ru估算量重新设置一遍。资源组一多,非常崩溃。
即便文档有这么一句:

https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control#常见问题
1. 当各个资源组设置的用量 (RU_PER_SEC) 总和超出系统容量会发生什么?TiDB 在创建资源组时不会检查容量。只要系统有足够的空闲资源,TiDB 就会满足每个资源组的用量设置。当系统资源超过限制时,TiDB 会优先满足高优先级 (PRIORITY) 资源组的请求。如果同一优先级的请求无法全部满足,TiDB 会根据用量 (RU_PER_SEC) 的大小按比例分配。

也只能说在缩容的场景下不用重新设置。扩容的场景下,还是的改一遍资源组设置。

不过总体来说。假如你的资源绷的很紧,比如我这种乞丐版4c8g的集群。资源管控还是能显著提升整个集群的稳定性。瑕不掩瑜。

稍微有点跑题了哈,我说的其实是权限问题,现在就是不够细致,功能实现第一,可以理解。

至于你说的两个问题,

  1. 其实也分读写,wru/rru就是这么来的
    至于语句级,主要为了解决bad sql问题,dba设定binding就直接可以把app发来的sql摁下。

  2. 百分比这个事情很难把控,百分比也是要落地到具体ru的。
    至于崩溃的诱因,tidb的白屏确实是短板,如果这方面加强,就不会崩溃了。

也不算跑题吧。

或者我换个说法,我现在这个用户,甭管他什么原因,就是要从600ru的组换到400ru这个组.这两个组都存在。但他现在默认就是600ru这个组的用户。
如果他只能看到600ru和默认资源组。
他又该怎么切换呢?

如果他不能看到全部资源组(这个400ru就看不到),但是可以切换过去,非常奇怪吧。
所以我理解在这个情况下,看到所有资源组,可能是绕不开的。

能看到的,我文章里有写。

在我看来不奇怪的,我也写在文章里了,只是没体现到某个帖子上,在我看来就是权限缺失导致的问题。

1 个赞

我的想法可能比较粗浅。毕竟我不是专业的dba。
你的文章可能还没放出来,到时候我了解一下。 :joy:
我猜想应该是资源组和用户之间做个多对多来控制权限。
这样确实是比现在好。

刚交作业。。。

1 个赞

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。