。

当涉及到新增配置项或系统变量时#xff0c;通常会为其指定一个明确的取值范围或定义一个专门的合法性检查函数。

本文将详细阐述在不同情境下#x…在“OceanBase

配置项系统变量实现及应用详解”的系列文章中我们已经对配置项和系统变量的源码进行了解析。

当涉及到新增配置项或系统变量时通常会为其指定一个明确的取值范围或定义一个专门的合法性检查函数。

本文将详细阐述在不同情境下应如何对配置项和系统变量进行合法性检查。

配置项通常可以直接设定其取值范围或者根据需要自定义合法性检查函数。

此外在某些情况下还需要通过访问特定的配置项甚至系统变量才能确定是否满足修改条件

常规检查

在定义配置项时对于基础类型的数据一般会指定一个“取值范围”。

比如[0,100]表示0到100之间的整数方括号表示包含0和100[0M,)表示范围从0到无穷大M是数据的单位它还可以是K、G等。

DEF_INT(cpu_count,

integer,ObParameterAttr(Section::OBSERVER,

Source::DEFAULT,

EditLevel::DYNAMIC_EFFECTIVE));

cpu_count

对于有的配置项无法用一个简单的字符串来描述它的取值范围就需要定义一个专门的检查函数。

DEF_STR_WITH_CHECKER(default_compress_func,

zstd_1.3.8,common::ObConfigCompressFuncChecker,default

compress

zstd_1.3.8,ObParameterAttr(Section::OBSERVER,

Source::DEFAULT,

EditLevel::DYNAMIC_EFFECTIVE));

合法性检查类有固定的模板可以使用只需模仿已有的结构定义即可。

关键在于check函数的功能比如

ObConfigCompressFuncChecker::check

compress_funcs

ObConfigCompressFuncChecker::check(const

ObConfigItem

ARRAYSIZEOF(common::compress_funcs)

!is_valid;

ObString::make_string(compress_funcs[i]).case_compare(t.str()))

{is_valid

{lz4_1.0,none,snappy_1.0,zstd_1.0,zstd_1.3.8,lz4_1.9.1,

合法性检查示例

有的配置项可能会依赖其他配置项的值比如A必须大于B、A*B要小于C等要求这时候就需要在检查函数中访问其他配置项的值从而判断当前传入的新值是否符合要求。

例如租户配置项

max_stale_time_for_weak_consistency不能小于集群配置项

weak_read_version_refresh_interval超时时间必须大于刷新时间不然来不及刷新很可能会超时那么在它的

check

ObConfigStaleTimeChecker::check(const

ObConfigItem

ObConfigTimeParser::get(t.str(),

is_valid);if

GCONF.weak_read_version_refresh_interval);if

(!is_valid)

{LOG_USER_ERROR(OB_NOT_SUPPORTED,

max_stale_time_for_weak_consistency

violate

weak_read_version_refresh_interval,);}}return

is_valid;

max_stale_time_for_weak_consistency

合法性检查示例

对于某些配置项可能需要跟另一个租户配置项进行对比而租户配置项存在多个实例显然无法直接通过

GCONF

partition_balance_schedule_interval

为例首先定义一个常量字符串

PARTITION_BALANCE_SCHEDULE_INTERVAL

来表示该配置项在配置项预检查函数

tenant_id注意不是所有租户只是当前修改命令涉及的租户依次获取每个租户的

tenant_config从中取出配置项

balancer_idle_time然后与传入的值进行对比若所有租户全部检查通过则可以修改。

else

PARTITION_BALANCE_SCHEDULE_INTERVAL))

{const

item-tenant_ids_.at(i);omt::ObTenantConfigGuard

tenant_config(TENANT_CONF(tenant_id));int64_t

balancer_idle_time

tenant_config-balancer_idle_time

DEFAULT_BALANCER_IDLE_TIME;int64_t

interval

ObConfigTimeParser::get(item-value_.ptr(),

valid);if

err_msg[DEFAULT_BUF_LENGTH];(void)snprintf(err_msg,

sizeof(err_msg),

partition_balance_schedule_interval

tenant

tenant_id);LOG_USER_ERROR(OB_INVALID_ARGUMENT,

err_msg);}}if

OB_INVALID_ARGUMENT;LOG_WARN(config

invalid,

partition_balance_schedule_interval

合法性检查示例

partition_balance_schedule_interval

1800s

partition_balance_schedule_interval

不能小于

partition_balance_schedule_interval

1800s

partition_balance_schedule_interval

1800s

partition_balance_schedule_interval

1800s

配置项还可能受到系统变量的影响有时也需要检查全局系统变量的值这就要从schema中获取系统变量进行比较。

max_stale_time_for_weak_consistency为例同样地首先为目标配置项定义一个常量字符串

WEAK_READ_VERSION_REFRESH_INTERVAL。

在配置项预检查函数

set_config_pre_hook

匹配到该配置项则可以进行后续的检查代码较多的情况下可以封装一个函数check_weak_read_version_refresh_interval用于检查合法性。

const

WEAK_READ_VERSION_REFRESH_INTERVAL

weak_read_version_refresh_interval;int

ObRootService::set_config_pre_hook(obrpc::ObAdminSetConfigArg

arg)

WEAK_READ_VERSION_REFRESH_INTERVAL))

{int64_t

ObConfigTimeParser::get(item-value_.ptr(),

valid);if

OB_FAIL(check_weak_read_version_refresh_interval(refresh_interval,

valid)))

OB_INVALID_ARGUMENT;LOG_WARN(config

invalid,

check_weak_read_version_refresh_interval

函数先从

ObRootService::check_weak_read_version_refresh_interval(int64_t

refresh_interval,

(OB_FAIL(GCTX.schema_service_-get_tenant_schema_guard(OB_SYS_TENANT_ID,

sys_schema_guard)))

(OB_FAIL(sys_schema_guard.get_tenant_ids(tenant_ids)))

{LOG_WARN(get

(OB_FAIL(GCTX.schema_service_-get_tenant_schema_guard(tenant_id,

schema_guard)))

(OB_FAIL(schema_guard.get_tenant_system_variable(tenant_id,OB_SV_MAX_READ_STALE_TIME,

var_schema)))

(OB_FAIL(var_schema-get_value(NULL,

NULL,

(OB_FAIL(obj.get_int(session_max_stale_time)))

{LOG_WARN(get

share::ObSysVarFactory::INVALID_MAX_READ_STALE_TIME

refresh_interval

false;LOG_USER_ERROR(OB_INVALID_ARGUMENT,weak_read_version_refresh_interval

larger

weak_read_version_refresh_interval

合法性检查示例

weak_read_version_refresh_interval

global

ob_max_read_stale_time系统变量需要大于等于

weak_read_version_refresh_interval配置项修改

global

weak_read_version_refresh_interval

常规检查

connect_timeout设置了min_val和max_val字段取值范围就是[2,

31536000]不需要自己增加额外的代码现有的框架会自动进行范围检查。

connect_timeout:

(OB_FAIL(val.get_varchar(log_level)))

{LOG_WARN(fail

log_level.case_compare(disabled))

{//allowed

(OB_FAIL(OB_LOGGER.parse_check(log_level.ptr(),

{LOG_WARN(Log

同样的系统变量也需要访问其他的配置项或者变量从而判断传入值的合法性。

检查集群配置项

获取其他集群级别配置项的值对比当前传入的值是否合法不合法则返回

int

ObVariableSetExecutor::update_global_variables(

{......}

(OB_FAIL(val.get_int(max_read_stale_time)))

{LOG_WARN(fail

ObSysVarFactory::INVALID_MAX_READ_STALE_TIME

max_read_stale_time

GCONF.weak_read_version_refresh_interval)

{ret

OB_INVALID_ARGUMENT;LOG_USER_ERROR(OB_INVALID_ARGUMENT,max_read_stale_time

smaller

weak_read_version_refresh_interval);}

合法性检查示例

函数中调用相应的处理函数相关的判断逻辑与global变量一致即可。

OB_INLINE

ObBasicSessionInfo::process_session_variable(ObSysVarClassType

var,

(process_session_log_level(val),

val);break;}

目前代码中没有这样的例子如果需要在更新系统变量时检查租户配置项可以参考更新配置项时的做法。

而且系统变量只涉及当前租户所以也只需要获取当前租户的配置项进行合法性检查。

检查系统变量

schema然后取得需要的系统变量的值。

获取的方式与“更新配置项时检查全局系统变量”类似不再赘述。

对于session变量在

通过自定义的合法性检查手段对配置项和系统变量的值进行检查可以有效避免用户设置无效的、超出正常边界的值进而影响系统稳定性和可用性。

至此关于配置项和系统变量的使用方法和源码分析已经介绍完了接下来还会有一些应用和问题排查相关的文章感兴趣的同学可以关注下。

参考文档