OceanBase v4.2 解读:tenant=all 语义优化,提升易用性

2024-06-07 09:04

本文主要是介绍OceanBase v4.2 解读:tenant=all 语义优化,提升易用性,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1 背景

1.1 租户类型及特点

OceanBase中有三种类型的租户:

  • sys租户:集群默认创建,生命周期与集群相一致,管理集群和其他租户,具有较高的地位。
  • 用户租户:用户创建的业务租户或普通租户,用于运行用户业务并提供完整的数据库功能。
  • meta租户:与用户租户对应的内部租户,用于存储和管理用户租户的集群私有数据。

可见,sys租户和meta租户都具有“角色关键,但不跑业务”的特点,因此,用户在运维中也往往不会刻意关注这些租户,而是将重点放在用户租户上。

1.2 tenant=all 的已知问题

目前,租户级配置项修改命令支持tenant=all语法,即alter system set xxx=yyy tenant=all,语义是对所有租户,包括sys、meta租户,都生效。这种设计存在两个问题。

一是易用性问题,即可能使用户做出不符合本身意愿的误操作。当用户使用tenant=all时,可能仅仅是想对所有用户租户生效,也没有清楚而深刻地认识到“我这个动作,已经顺带把sys租户和meta租户的配置项一起改了,这可能会有问题,我需要特别留心这一点”。

二是稳定性问题,即可能会引发observer故障。如果有些配置项对sys租户很重要,不可轻易修改,那么,一旦这些配置项被tenant=all“顺带”修改了,就可能引发ObServer的故障,并增加问题排查的难度。

cpu_quota_concurrency为例说明,sys租户默认配置成10,其余租户默认值为4,如果用户执行了alter system set cpu_quota_concurrency=5 tenant=all;,可能导致sys租户出现问题。而用户很可能仅仅是想改跑业务的用户租户的配置项,sys、meta被连带修改,非用户本意。

1.3 解决方案

变更tenant=all的语义,彻底杜绝用户误操作的风险,同时新增语法兼容旧语义,详见下文变更细节。

2 tenant=all语义变更

2.1 变更细节

首先,修改tenant=all语义,改为“仅包括所有用户租户,排除sys和meta租户”,以彻底杜绝用户误操作风险,提升产品稳定性。

除了配置项修改语法,其它使用tenant=all的语法,如合并转储相关语法,也要一起修改,为了保持产品行为统一,避免用户疑惑。

其次,新增语法,tenant=all_usertenant=all_meta,分别对应所有用户租户和所有meta租户。理由是兼容原有语义,提供更细粒度的控制,在保证操作安全的前提下尽量方便用户使用。如果用户想使操作对所有用户租户生效,可以使用tenant=all_user,而不必一一列举租户名称;如果用户确实想要使操作对所有租户都生效,可以依次使用tenant=all_usertenant=all_metatenant=sys,详见使用说明。

修改后,tenant=alltenant=all_user的语义完全相同,后面会在恰当时机废弃tenant=all

2.2 影响到的模块和命令

模块命令
配置项修改alter system set xxx=yyy tenant=all
合并转储alter system {major|minor} freeze tenant=allalter system {suspend|resume} merge tenant=allalter system clear merge error tenant=all

2.3 性能影响

无影响。本特性只是缩小了tenant=all的生效范围,同时新增了两个与tenant=all类似的命令,即(tanant=all_usertenant=all_meta),且实现上没有新增开销大的操作,因此不会增加额外的运行负担,对数据库性能无影响。

3 使用说明及特性限制

  • 仅支持在sys租户下使用tenant=systenant=all_usertenant=all_meta
  • 对配置项修改语法和合并转储语法,均建议再使用tenant=all
  • 如果只想对sys租户生效,使用tenant=sys;如果只想对所有的用户租户生效,使用tenant=all_user;如果只想对所有的meta租户生效,使用tenant=all_meta
  • 如果确实想对所有的租户生效,则需依次使用tenant=systenant=all_usertenant=all_meta
  • 对于配置项设置语法,tenant后不支持list形式;对于合并转储语法,all_user和all_meta只能单独使用,其它名称可以组合成list形式使用。
  • sys不能大写,因为sys是租户名,是区分大小写的。而all_user和all_meta是关键字,不区分大小写。

# 配置项设置示例
# 以下三句实现原有all语义
alter system set ob_compaction_schedule_interval = '10s' tenant = sys; # sys不能大写
alter system set ob_compaction_schedule_interval = '10s' tenant = all_user;
alter system set ob_compaction_schedule_interval = '10s' tenant = all_meta;# 以下示例不可以,tenant后只能是单个名称,不能是list
obclient> alter system set ob_compaction_schedule_interval = '10s' tenant = mysql,sys;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near 'sys' at line 1obclient> alter system set ob_compaction_schedule_interval = '10s' tenant = all_user,all_meta;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near 'all_meta' at line 1obclient> alter system set ob_compaction_schedule_interval = '10s' tenant = mysql,all_user;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near 'all_user' at line 1obclient> alter system set ob_compaction_schedule_interval = '10s' tenant = mysql,all_meta;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near 'all_meta' at line 1# 合并转储示例
# 以下三句实现原有all语义
alter system major freeze tenant = sys; # sys不能大写
alter system major freeze tenant = all_user;
alter system major freeze tenant = all_meta;# 以下示例不可以,all_user/all_meta只能单独使用
obclient> alter system major freeze tenant = all_user,all_meta;
ERROR 1235 (0A000): all/all_user/all_meta in combination with other names is not supportedobclient> alter system major freeze tenant = mysql,all_user;
ERROR 1235 (0A000): all/all_user/all_meta in combination with other names is not supportedobclient> alter system major freeze tenant = mysql,all_meta;
ERROR 1235 (0A000): all/all_user/all_meta in combination with other names is not supported# 以下示例是可以的,all_user/all_meta外的名称可以组合使用
alter system major freeze tenant = tt1,sys;

在使用该特性的过程中,存在一些限制。

第一,不能再创建名为all_user或者all_meta(不区分大小写)的租户,因为all_user和all_meta变成保留字了。

第二,低版本升级4.2.1版本前,需要先检查集群中是否有名为all_user或者all_meta(不区分大小写)的租户,如有,需要先重命名租户再升级。

第三,因为没有实际风险,故以下语法中tenant=all语义暂未变更,且暂无计划在未来版本做变更,会维持原有语义不变,且不支持tenant=all_usertenant=all_meta

# 升级相关命令,不显示指定TENANT,或指定TENANT = ALL,都会对所有租户生效,无风险
ALTER SYSTEM RUN UPGRADE JOB "CMD" [TENANT = ALL|tenant_list];
# 这里TENANT = ALL只包含用户租户,sys租户和meta租户没有对应功能
ALTER SYSTEM ARCHIVELOG|NOARCHIVELOG TENANT = ALL;

这篇关于OceanBase v4.2 解读:tenant=all 语义优化,提升易用性的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1038737

相关文章

Oracle查询优化之高效实现仅查询前10条记录的方法与实践

《Oracle查询优化之高效实现仅查询前10条记录的方法与实践》:本文主要介绍Oracle查询优化之高效实现仅查询前10条记录的相关资料,包括使用ROWNUM、ROW_NUMBER()函数、FET... 目录1. 使用 ROWNUM 查询2. 使用 ROW_NUMBER() 函数3. 使用 FETCH FI

C#使用HttpClient进行Post请求出现超时问题的解决及优化

《C#使用HttpClient进行Post请求出现超时问题的解决及优化》最近我的控制台程序发现有时候总是出现请求超时等问题,通常好几分钟最多只有3-4个请求,在使用apipost发现并发10个5分钟也... 目录优化结论单例HttpClient连接池耗尽和并发并发异步最终优化后优化结论我直接上优化结论吧,

Java内存泄漏问题的排查、优化与最佳实践

《Java内存泄漏问题的排查、优化与最佳实践》在Java开发中,内存泄漏是一个常见且令人头疼的问题,内存泄漏指的是程序在运行过程中,已经不再使用的对象没有被及时释放,从而导致内存占用不断增加,最终... 目录引言1. 什么是内存泄漏?常见的内存泄漏情况2. 如何排查 Java 中的内存泄漏?2.1 使用 J

MySQL中时区参数time_zone解读

《MySQL中时区参数time_zone解读》MySQL时区参数time_zone用于控制系统函数和字段的DEFAULTCURRENT_TIMESTAMP属性,修改时区可能会影响timestamp类型... 目录前言1.时区参数影响2.如何设置3.字段类型选择总结前言mysql 时区参数 time_zon

C#使用yield关键字实现提升迭代性能与效率

《C#使用yield关键字实现提升迭代性能与效率》yield关键字在C#中简化了数据迭代的方式,实现了按需生成数据,自动维护迭代状态,本文主要来聊聊如何使用yield关键字实现提升迭代性能与效率,感兴... 目录前言传统迭代和yield迭代方式对比yield延迟加载按需获取数据yield break显式示迭

MySQL中的锁和MVCC机制解读

《MySQL中的锁和MVCC机制解读》MySQL事务、锁和MVCC机制是确保数据库操作原子性、一致性和隔离性的关键,事务必须遵循ACID原则,锁的类型包括表级锁、行级锁和意向锁,MVCC通过非锁定读和... 目录mysql的锁和MVCC机制事务的概念与ACID特性锁的类型及其工作机制锁的粒度与性能影响多版本

Redis过期键删除策略解读

《Redis过期键删除策略解读》Redis通过惰性删除策略和定期删除策略来管理过期键,惰性删除策略在键被访问时检查是否过期并删除,节省CPU开销但可能导致过期键滞留,定期删除策略定期扫描并删除过期键,... 目录1.Redis使用两种不同的策略来删除过期键,分别是惰性删除策略和定期删除策略1.1惰性删除策略

MySQL不使用子查询的原因及优化案例

《MySQL不使用子查询的原因及优化案例》对于mysql,不推荐使用子查询,效率太差,执行子查询时,MYSQL需要创建临时表,查询完毕后再删除这些临时表,所以,子查询的速度会受到一定的影响,本文给大家... 目录不推荐使用子查询和JOIN的原因解决方案优化案例案例1:查询所有有库存的商品信息案例2:使用EX

MySQL中my.ini文件的基础配置和优化配置方式

《MySQL中my.ini文件的基础配置和优化配置方式》文章讨论了数据库异步同步的优化思路,包括三个主要方面:幂等性、时序和延迟,作者还分享了MySQL配置文件的优化经验,并鼓励读者提供支持... 目录mysql my.ini文件的配置和优化配置优化思路MySQL配置文件优化总结MySQL my.ini文件

Redis与缓存解读

《Redis与缓存解读》文章介绍了Redis作为缓存层的优势和缺点,并分析了六种缓存更新策略,包括超时剔除、先删缓存再更新数据库、旁路缓存、先更新数据库再删缓存、先更新数据库再更新缓存、读写穿透和异步... 目录缓存缓存优缺点缓存更新策略超时剔除先删缓存再更新数据库旁路缓存(先更新数据库,再删缓存)先更新数