配置 SQL 级资源隔离

SQL 级资源隔离主要是通过将满足某个条件的 SQL 绑定到指定资源组上执行来实现的。本文主要介绍了 MySQL 模式下 SQL 级的资源隔离的配置方法。

前提条件

• 开始配置 SQL 级资源隔离前，建议您先了解资源组、资源管理计划、资源管理计划内容等基础概念，SQL 级资源隔离相关的基础概念及适用场景请参见 资源隔离概述。

• 配置 SQL 级资源隔离前，必须配置 cgroup 目录并开启 cgroup 功能。配置 cgroup 目录并开启 cgroup 功能的相关操作请参见 配置 cgroup。

• 在进行 IOPS 资源隔离前，需要先进行磁盘性能校准，磁盘性能校准的相关操作请参见 磁盘性能校准。

  如果仅需要控制 CPU 的资源隔离，则不需要进行磁盘性能校准。

• 请确认已创建好需要进行资源隔离的用户、数据库、表及列。

操作步骤

以下示例中，将不同的 SQL 条件绑定在 interactive_group 和 batch_group 2 个资源组上，再通过资源管理计划 daytime 来控制不同的 SQL 语句使用不同的 CPU 资源和 IOPS 资源。

1. 租户管理员登录集群的 MySQL 租户。

2. 调用 DBMS_RESOURCE_MANAGER 系统包中的 CREATE_CONSUMER_GROUP 子程序，创建 2 个资源组。

   obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
   CONSUMER_GROUP => 'interactive_group' ,
   COMMENT => 'TP'
   );
   
   obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
   CONSUMER_GROUP => 'batch_group' ,
   COMMENT => 'AP'
   );
   

   相关参数说明如下：

   • CONSUMER_GROUP：定义资源组名称。

   • COMMENT：填写资源组的备注信息。

   创建成功后，可以查询 oceanbase.DBA_RSRC_CONSUMER_GROUPS 视图进行确认。有关 oceanbase.DBA_RSRC_CONSUMER_GROUPS 视图的详细介绍请参见 oceanbase.DBA_RSRC_CONSUMER_GROUPS。

3. 调用 DBMS_RESOURCE_MANAGER 系统包中的 CREATE_PLAN 子程序，创建资源管理计划。

   obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN(
   PLAN => 'daytime',
   COMMENT => 'TP优先');
   

   相关参数说明如下：

   • PLAN：定义资源管理计划名称。

   • COMMENT：填写资源管理计划的备注信息。

   创建成功后，可以查询 oceanbase.DBA_RSRC_PLANS 视图进行确认。有关 oceanbase.DBA_RSRC_PLANS 视图的详细介绍请参见 oceanbase.DBA_RSRC_PLANS。

4. 调用 DBMS_RESOURCE_MANAGER 系统包中的 CREATE_PLAN_DIRECTIVE 子程序，创建资源管理计划内容。用于启用资源管理计划时，限制资源组所使用的 CPU 资源和 IOPS 资源。

   obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
   PLAN => 'daytime',
   GROUP_OR_SUBPLAN => 'interactive_group' ,
   COMMENT  => '',
   MGMT_P1 => 30,
   UTILIZATION_LIMIT =>80,
   MIN_IOPS => 30,
   MAX_IOPS => 90,
   WEIGHT_IOPS => 80);
   
   obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
   PLAN => 'daytime',
   GROUP_OR_SUBPLAN => 'batch_group' ,
   COMMENT  => '',
   MGMT_P1 => 50,
   UTILIZATION_LIMIT => 40,
   MIN_IOPS => 40,
   MAX_IOPS => 80,
   WEIGHT_IOPS => 70);
   

   相关参数说明如下：

   • PLAN：指定资源管理计划名称。

   • GROUP_OR_SUBPLAN：指定资源组。

   • COMMENT：填写资源管理计划内容的备注信息，默认值为 NULL。

   • MGMT_P1：指定系统满负载情况下，承诺分配给本资源组的 CPU 占比。默认值为 100。

   • UTILIZATION_LIMIT：指定资源组使用的 CPU 资源的上限。该参数的默认值为 100，取值范围为 (0, 100]。100 表示最大可使用租户全部 CPU 资源。如果取值为 70 则表示最大可使用租户 70% 的 CPU 资源。

   • MIN_IOPS：用于出现 IO 争用时，资源组预留的 IOPS 资源，总和不超过 100，默认值为 0。

   • MAX_IOPS：用于指定资源组最大可使用的 IOPS 资源，总和可以超过 100，默认值为 100。

   • WEIGHT_IOPS：用于指定 IOPS 的权重值，总和可以超过100，默认值为 0。

   创建成功，可以查询 oceanbase.DBA_RSRC_PLAN_DIRECTIVES 视图和 oceanbase.DBA_OB_RSRC_IO_DIRECTIVES 视图进行确认。

   有关 oceanbase.DBA_RSRC_PLAN_DIRECTIVES 视图的详细介绍请参见 oceanbase.DBA_RSRC_PLAN_DIRECTIVES。

   有关 oceanbase.DBA_OB_RSRC_IO_DIRECTIVES 视图的详细介绍，请参见 oceanbase.DBA_OB_RSRC_IO_DIRECTIVES。

5. 调用 DBMS_RESOURCE_MANAGER 系统包中的 SET_CONSUMER_GROUP_MAPPING子程序，创建 SQL 级资源隔离匹配规则。

   obclient [test]> CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
   ATTRIBUTE => 'column',
   VALUE => 'test.t.c3=3 for tp_user',
   CONSUMER_GROUP => 'batch_group');
   
   obclient [test]> CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
   ATTRIBUTE => 'column',
   VALUE => 't.c3=5',
   CONSUMER_GROUP => 'interactive_group');
   

   相关参数说明如下：

   • ATTRIBUTE：指定属性类型，column 表示 SQL 级资源隔离，user 表示用户级 user 资源隔离，function 表示用户级 function 资源隔离，属性名称不区分大小写。

   • VALUE：指定属性值，包括库名、表名、列名、常量值和用户名等信息。

     其中：

     • 库名和用户名为可选，默认库名为当前库名，如果未指定用户名，则对所有用户生效，包括当前租户中后续新建的用户。

     • 表名、列名、常量值为必选项，并且每项只能指定一个值。在指定常量值时，仅支持指定为数值或字符串。

     • 在指定表名、列名、用户名时，指定的表、列和用户必须存在。

   • CONSUMER_GROUP：指定需要绑定的资源组。表示当 SQL 命中 VALUE 中所设置的匹配规则后，需要绑定在哪个资源组上执行该语句。当前仅支持绑定一个资源组。

   本示例中，添加以上资源隔离匹配规则后，当用户 tp_user 执行的一条 WHERE 条件中包含 test.t.c3 = 3 的 SQL 语句时，这条 SQL 语句就会绑定到名为 batch_group 的资源组上执行。

   注意

   执行 SQL 语句时，并不需要语句中必须包含 test.t.，只需要 c3 最终被解析为 test.t.c3，则该 SQL 语句就会绑定到名为 batch_group 的资源组上执行。例如：SELECT * FROM test.t WHERE c3 = 1;。

   创建成功后，可以查询 oceanbase.DBA_RSRC_GROUP_MAPPINGS 视图进行确认。有关 oceanbase.DBA_RSRC_GROUP_MAPPINGS 视图的详细介绍请参见 oceanbase.DBA_RSRC_GROUP_MAPPINGS。

6. 为资源组启用合适的资源管理计划。

   由于不同的资源管理计划中，同一个资源组被限制的资源可能不同。您需要为资源组启用合适的资源管理计划。

   obclient [test]> SET GLOBAL resource_manager_plan = 'daytime';
   

   说明

   如果不需要对资源进行限制，可以使用 SET GLOBAL resource_manager_plan = ''; 语句禁用所有资源计划。

配置后注意事项

• 资源隔离匹配规则添加后，如果删除了用户后再重建，资源隔离匹配规则仍然适用。

• 资源隔离匹配规则添加成功后不是立即生效，预计可能在 10 秒内开始生效，具体以实际环境为准。

• SQL 级资源隔离优先级高于用户级资源隔离。

• 资源隔离匹配规则添加后，目前仅在 SELECT、INSERT、UPDATE、DELETE 等语句中生效，在 DDL 和 DCL 语句中不生效，在 PL 中也不生效。在 prepareStatement 中可以生效。

配置后的性能影响

SQL 级资源隔离对性能的影响主要来自重试。不同于用户级资源隔离在一条 SQL 未解析前就确定了应该使用哪个资源使用组的资源，SQL 级资源隔离在 SQL 解析或命中 Plan Cache 时，才能确定应该使用哪个资源使用组的资源，此时如果发现应该使用的资源组与当前正在使用的不同，那么系统就会执行一次重试，使用匹配规则对应的资源使用组的资源来处理这条 SQL。

SQL 级资源隔离对性能的影响主要分为以下三种情况：

1. 当一条 SQL 未匹配到任意一条规则时，对性能几乎没有影响。

2. 当一条 SQL 匹配到一条规则时，假设该规则所指定的资源使用组为 batch_group, 不仅本 SQL 最终会以 batch_group 的资源执行，下一条 SQL 也会先以 batch_group 的资源执行，直到匹配到规则发现需要切换到其他资源组，系统才会进行重试。对于连续执行一批 SQL，并且这些 SQL 均绑定在同一个资源组上的场景，使用该策略可以实现仅处理一批中的第一条 SQL 时需要重试，后续 SQL 都不再需要重试。尽量减少了重试，对性能影响较小。

3. 当每一条 SQL 预期使用的资源组都与上一条不同，则每一条 SQL 都需要重试一次，对性能的影响较大。

相关文档

用户级资源隔离