Skip to content

关于kunlun_cluster的mysql变量通道及后端存储节点的权限赋予

kunlundb edited this page Oct 9, 2021 · 1 revision

“由于我们kunlun_cluster的计算节点用的是postgresql,而存储节点使用的是mysql,为了方便用户可以在计算节点中设置操作存储节点的系统变量,需要一个计算节点和存储节点之间的通道,于是便有了该功能 ”

目前为止都做了什么:

对应脚本从https://gitee.com/zettadb/kunlun.git 上面拉下来,有一个vars.sql文件。

1.使 set [shard] global/session/local/PERSIST/PERSIST_only VARNAME=VALUE的语法 生效;总是假设VARNAME是mysql的;他会发送语句给所有的存储节点去执行,且session 变量中值会在计算节点里面缓存,在切换主节点时,新的主节点会校正session状态。

set session innodb_lock_wait_timeout = 3;

set shard global innodb_lock_wait_timeout = 4;

示例出现的问题???将在后续版本修复

set shard persist_only innodb_lock_wait_timeout = 11;(该错误是因为后端存储节点的权限缺失引起的,若出现该问题可以参考此文章的后半段)

2.set VARNAME=VALUE 语句,在pg客户端连接的时候会默认以pg的变量名来看待他们,如果变量名不存在,则会把他们看成是mysql的session变量。在mysql客户端连接时,会默认把他们视为mysql的session变量,如果变量名不存在则把他们视为pg变量。

set innodb_lock_wait_timeout = 2;

3.除了debug_sync之外,总是缓存mysql配对的session var-value,且如果shard连接被重新设置或者重新连接会把他们发送给mysql。

  1. 也支持 set @@global/session/local/persist/persist_only.varname=value 语句,且总是假定为mysql变量,但因 ‘shift/reduce’冲突而不支持set @@VARNAME=VALUE。

set @@global.innodb_lock_wait_timeout = 4;

示例的问题???会在后续版本修复

set @@innodb_lock_wait_timeout = 2;(不支持该语法)

5.支持 show [session/local/global] variables like 'wildcard-filter' 语法且总是假定是mysql变量,自从pg私有语法且不再共享语法,为了默认'show varname' 语法总是先假定是pg变量。如果变量名不是pg变量,则被假定是mysql变量

show global variables like 'innodb_lock_wait_timeout';

show session variables like 'innodb_lock_wait_timeout';

show local variables like 'innodb_lock_wait_timeout';

6.支持在kunlun 计算节点里面的选项 'show [session/global/local] variables like ' 里选择 'STRICT' 来展示只有mysql识别或者支持的变量。

show local variables like 'innodb_lock_wait_timeout' strict;

show session variables like 'innodb_lock_wait_timeout' strict;

show global variables like 'innodb_lock_wait_timeout' strict;

7.当执行'show' 语句时会取得一个变量的值,直接发送给任意存储shard来获取他的值。

“由于set @varname=value 可能会导致 ‘shift/reduce’冲突且该功能相对来说比较少地被使用,所以我们不支持该语法。 ”

** 后端存储节点赋权**

如果在set persist_only 变量时出现权限不够的提示(如下图),则可以使用以下方法获取权限

因为该问题是后端mysql权限的问题,所以我们要进入到mysql后台:

  1. 通过ps -ef | grep mysqld来查看当前的mysql 后台进程

查看对应的mysql用户,当前的linux用户要切换到对应用户:

如上图 --user=kunlun,则需要su kunlun(如果不切换就会提示无法打开对应文件而进不去)

2.进入mysql后台:(根据ps出来的进程,选择对应的--defaults-file)

进入mysql后台的方式是mysql --defaults-file= defaults-file -uxxx -pxxx

(因为更改权限是权限很高的用户才可以操作,所以我们使用root用户登录进去)

因为对应的权限表在mysql数据库里面,所以我们要先切换到数据库mysql

3.kunlun_cluster 的默认mysql存储节点用户是pgx,所以我们要赋权给pgx

可以先查看当前的用户表的用户和对应的主机地址,方便后续操作

根据一开始的错误提示得知,我们缺少这两个权限:PERSIST_RO_VARIABLES_ADMIN、SYSTEM_VARIABLES_ADMIN

所以我们要给pgx赋这两个权限:(database和table可以用*代表全部)

GRANT 权限 on database.table TO ‘user’@’host’ WITH GRANT OPTION;

根据我们自身的需求,可以写成如下语句:

GRANT PERSIST_RO_VARIABLES_ADMIN,SYSTEM_VARIABLES_ADMIN ON *.* TO 'pgx'@'%' WITH GRANT OPTION;

最后exit退出后端mysql,再次通过psql方式进入计算节点验证是否可以正常设置

成功!!!

“如果还是出一样的错就说明设置了错的存储节点,一般是选择我们设置的data-shard里primary-node 里面pgx用户的权限。Data-shard正常来说不止一个,所以一个不行就要去设置另一个shard里的primary-node。 ”