OceanBase 的系统变量、配置项和用户变量有何差异

在继续阅读本文之前,大家不妨先思考一下,数据库中“系统变量”、“用户变量”以及“配置项”这三者之间有何不同。如果感到有些模糊,那么本文将是您理清这些概念的好帮手。

很多用户在使用OceanBase数据库中的“配置项”和“系统变量”,但可能未能完全理解它们之间的区别。在社区论坛里,也看到一个帖子,该帖子询问“系统变量”与“用户变量”有何不同,还提及了“用户变量”。

1728720645

下面有不少热心用户积极回复,但感觉完全讲清楚两者区别的并不多,有一些同学还把 “配置项” 也掺进来一起讨论。所以想趁机搞明白这三者之间的区别,在这里分享给大家。为了解释的更清楚,在下面的标题中,我会把 “系统变量” 称为 “租户系统变量”,把 “用户变量” 成为 “用户自定义变量”。

租户系统变量和配置项

OceanBase 数据库提供了 “系统变量” 和 “配置项” 两种不同的参数来对数据库的行为进行配置,使之能够符合业务的要求。

有很多用户可能还不了解系统变量和配置项的影响范围,例如某个参数的设置,是会影响整个集群,还是影响当前租户,亦或是只影响当前 session。所以先抛开用户变量,先说说这两个更常见和常用的东西。

租户系统变量

OceanBase 的系统变量都是组户级的,也就是只对当前的租户生效。所以系统变量又可以被称作:租户系统变量。

设置系统变量时,又可以通过增加 Global 关键字或者 Session 关键字,来设置对应系统变量为全局级别或者会话级别,以调整系统变量在租户内的生效范围:

  • 全局变量:表示 Global 级别的修改,数据库同一租户内的不同用户共享一个全局变量。全局变量的修改不会随会话的退出而失效。此外,全局变量修改后,对当前已打开的 Session 不生效,需要重新建立 Session 才能生效。
  • 会话变量:表示 Session 级别的修改,Session 变量的修改仅对当前 Session 生效。当新的客户端连接到数据库后,数据库会复制全局变量来自动生成对应连接上的 Session 变量。
-- 执行 show variables; 可以看到全量系统变量
obclient [test]> show variables like 'ob_query_timeout';
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| ob_query_timeout | 10000000 |
+------------------+----------+
1 row in set (0.004 sec)

-- 修改 global 级别的系统变量
obclient [test]> set global ob_query_timeout = 20000000;
Query OK, 0 rows affected (0.004 sec)

-- 全局变量修改后,对当前已打开的 session 不生效,需要重新建立 session 才能生效。
obclient [test]> show variables like 'ob_query_timeout';
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| ob_query_timeout | 10000000 |
+------------------+----------+
1 row in set (0.003 sec)

-- 不加 global 或者 session 关键字,默认修改的是 session 级别的系统变量
obclient [test]> set ob_query_timeout = 20000000;
Query OK, 0 rows affected (0.001 sec)

obclient [test]> show variables like 'ob_query_timeout';
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| ob_query_timeout | 20000000 |
+------------------+----------+
1 row in set (0.001 sec)

配置项

OceanBase 数据库的配置项分为集群级配置项和租户级配置项。

  • 集群级配置项:指适用于整个 OceanBase 数据库集群的配置选项,它们具有全局性质,用于配置整个集群的基本信息、性能参数、安全选项等等。这些配置项通常包括数据备份和恢复、负载均衡等方面的配置选项。集群级配置项通常是在集群启动时进行配置,配置后不轻易修改。
  • 租户级配置项:指适用于租户级别的配置选项,它们是针对单个租户或多个租户的配置选项。用于对单个租户或多个租户进行特定的配置和优化。这些配置项通常包括存储引擎参数、SQL 执行策略、访问控制等方面的配置选项。租户级配置项通常可以在租户创建和管理时进行配置,可以随时根据需要进行修改。

查询某个配置项为集群级别还是租户级别的方法如下:

obclient [test]> SHOW PARAMETERS; -- 展示所有配置项

obclient [test]> SHOW PARAMETERS like 'cpu_quota_concurrency'\G
*************************** 1. row ***************************
      zone: zone1
  svr_type: observer
    svr_ip: 11.158.31.20
  svr_port: 22602
      name: cpu_quota_concurrency
 data_type: NULL
     value: 4
      info: max allowed concurrency for 1 CPU quota. Range: [1,20]
   section: TENANT
     scope: TENANT
    source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE
1 row in set (0.004 sec)

obclient [test]> SHOW PARAMETERS like 'max_string_print_length'\G
*************************** 1. row ***************************
      zone: zone1
  svr_type: observer
    svr_ip: 11.158.31.20
  svr_port: 22602
      name: max_string_print_length
 data_type: NULL
     value: 500
      info: truncate very long string when printing to log file. Range:[0,]
   section: OBSERVER
     scope: CLUSTER
    source: DEFAULT
edit_level: DYNAMIC_EFFECTIVE
1 row in set (0.005 sec)

scope 列对应的值为 CLUSTER 表示该配置项的生效范围为整个集群;如果 scope 列对应的值为 TENANT,则表示该配置项的生效范围为当前租户。

edit_level 列对应的值为 DYNAMIC_EFFECTIVE 时表示修改后立即生效,为 STATIC_EFFECTIVE 时则表示需要在重启 OBServer 节点后生效。

注意:

上述的查询结果中有一个比较容易和 scope 混淆的 section 列,值可能为:LOAD_BALANCE、DAILY_MERGE、RPC、TRANS、LOCATION_CACHE 等等,甚至可能为 TENANT 或者 OBSERVER(上面的示例就专门展示了这种情况)。这个 section 仅仅是一个 tag,只有标签性质,表示这个配置项和哪个模块相关,不代表配置项的生效范围,大家切记要将 scope 和 section 列的含义区分开!

尤其是要注意类似于 TENANT 或者 OBSERVER 这种 tag,估计研发同学在写标签的时候实在不知道相应的配置项该归为哪个模块更合适了,就直接偷懒把标签打成了 TENANT 或者 OBSERVER,但这个标签并不代表对当前 tenant 或者当前 session 直连的某个 OBServer 生效。

最后附上一个配置项与系统变量的对比:

对比项配置项系统变量
生效范围分为集群、Zone、机器和租户。分为租户的 Global 或 Session 级别。
生效方式动态生效:edit_level 为 dynamic_effective 重启生效:edit_level 为 static_effective设置 Session 级别的变量仅对当前 Session 有效,对其他 Session 无效。 设置 Global 级别的变量对当前 Session 无效,需要重新登录建立新的 Session 才会生效。
修改方式支持通过 SQL 语句修改,示例: Alter SYSTEM SET schema_history_expire_time='1h';支持通过启动参数修改,示例: cd /home/admin/oceanbase && ./bin/observer -o "schema_history_expire_time='1h'";仅支持通过 SQL 语句修改,示例如下:MySQL 模式 SET ob_query_timeout = 20000000; SET GLOBAL ob_query_timeout = 20000000;
查询方式可以使用 SHOW PARAMETERS 语句查询。示例:SHOW PARAMETERS LIKE 'schema_history_expire_time';可以使用 SHOW [GLOBAL] VARIABLES 语句查询。示例如下:SHOW VARIABLES LIKE 'ob_query_timeout'; SHOW GLOBAL VARIABLES LIKE 'ob_query_timeout';
持久化持久化到内部表与配置文件,可以在 /home/admin/oceanbase/etc/observer.config.bin 与 /home/admin/oceanbase/etc/observer.config.bin.history 文件中查询该配置项。仅 Global 级别的变量会持久化,Session 级别的变量不会进行持久化。
生命周期长,从进程启动到退出。短,需要租户的 Schema 创建成功以后才生效。

用户自定义变量

发帖者提问中的 “用户变量” 其实就是“用户自定义变量”,一般会出现在 PL 的存储过程和匿名块之类的地方。

obclient [test]> SET @v3 = 789;
Query OK, 0 rows affected (0.002 sec)

obclient [test]> SHOW PROXYSESSION VARIABLES;
+-----------------------------------+--------------+-----------------+--------------------+--------------------------------------------+
| variable_name                     | value        | info            | modified_type      | sys_variable_flag                          |
+-----------------------------------+--------------+-----------------+--------------------+--------------------------------------------+
| ob_proxy_global_variables_version | 0            | changed sys var | cold modified vars |  && invisible && session_scope && readonly |
| ob_proxy_user_privilege           | 133009965054 | changed sys var | cold modified vars |  && invisible && session_scope && readonly |
| ob_capability_flag                | 916295       | changed sys var | cold modified vars |  && invisible && session_scope && readonly |
| ob_enable_transmission_checksum   | 1            | changed sys var | cold modified vars |  && global_scope && session_scope          |
| _min_cluster_version              | '4.2.1.2'    | user var        | cold modified vars |                                            |
| v3                                | 789          | user var        | cold modified vars |                                            |
+-----------------------------------+--------------+-----------------+--------------------+--------------------------------------------+
6 rows in set (0.001 sec)

obclient [test]> select concat('abc', @v3);
+--------------------+
| concat('abc', @v3) |
+--------------------+
| abc789             |
+--------------------+
1 row in set (0.002 sec)

obclient [test]> select power(@v3, 2);
+---------------+
| power(@v3, 2) |
+---------------+
|        622521 |
+---------------+
1 row in set (0.002 sec)

帖子中的链接里说的执行 SHOW PROXYSESSION VARIABLES 可以展示出来的用户变量,就是上面例子中用户自定义的 @v3 了。用户自定义变量在一般情况下的使用频率不会太高,所以就偷懒贴一个 官方文档的链接 供大家学习参考啦~

参考文档

OceanBase 官网的文档中心日渐完善,最后也在这里推荐大家自主在官网搜索和解决各类问题~

文档中心 - 配置项和系统变量概述

文档中心 - 用户自定义变量


OceanBase 云数据库现已支持免费试用,现在申请,体验分布式数据库带来全新体验吧 ~

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值