Resource isolation overview

This topic introduces the concepts, resource isolation methods, and application scenarios of resource isolation.

Control group (cgroup) is a mechanism provided by the Linux kernel to aggregate or divide, based on specialized behavior, a series of tasks and their subtasks into different groups that are graded based on resources, thereby providing a unified framework for system resource management.

In the current version of OceanBase Database, worker threads and most background threads are identified by tenant, and network threads are shared. After configuring the cgroup directory, administrators can use the DBMS_RESOURCE_MANAGER system package to control the CPU and IOPS usage of tenants.

DBMS_RESOURCE_MANAGER system package

In OceanBase Database, the procedural language (PL) package DBMS_RESOURCE_MANAGER is used to manage resource allocation in a database to implement resource isolation. This package is mainly used to maintain the following elements:

• Resource groups: A resource group is a collection of sessions that are grouped based on resource requirements. The system allocates resources to a resource group rather than to individual sessions.

• Resource management plans: A resource management plan is a container of plan directives and specifies how resources are allocated to resource groups. You can activate a specific resource management plan to control the allocation of resources. A resource management plan can contain multiple plan directives. However, a resource management plan must not contain two identical plan directives.

• Plan directives: A plan directive associates a resource group with a resource management plan and specifies how resources are allocated to this resource group.

For more information about the DBMS_RESOURCE_MANAGER system package, see DBMS_RESOURCE_MANAGER (Oracle-compatible mode) and DBMS_RESOURCE_MANAGER (MySQL-compatible mode).

Resource isolation methods

When you use the DBMS_RESOURCE_MANAGER package to configure resource isolation within a tenant, the following resource isolation methods are available based on the granularity of resource isolation:

• User-level resource isolation

  User-level resource isolation specifies the mapping between a user and a resource group. All SQL statements initiated by the specified user can be executed by using only the resources in the resource group mapped to the user.

• SQL statement-level resource isolation

  SQL statement-level resource isolation is more fine-grained than user-level resource isolation. You can bind the SQL statements that meet a specified condition to a specified resource group to implement SQL statement-level resource isolation. If multiple accounts exist in the business system, when an order of an account is processed, a transaction is enabled to execute a batch of SQL statements related to this account. Generally, the account is specified in the WHERE clause. Different accounts may involve different amounts of data. If accounts involving a large amount of data use up the CPU resources, the orders of accounts involving a small amount of data cannot be processed. You can bind SQL statements for processing different orders with different resource groups. In this way, SQL statements for different orders can use resources in different resource groups.

• Function-level resource isolation

  Function-level resource isolation specifies the mapping between a backend task and a resource group to isolate the resources used by each task. Function-level resource isolation is used to control the CPU and IOPS usage of backend tasks.

  The following backend tasks corresponding to the DAG thread are supported:

  • COMPACTION_HIGH: mini merge and DDL KV Merge tasks
  • HA_HIGH: high-priority high-reliability tasks such as replication, Rebuild, and restore
  • COMPACTION_MID: minor merge tasks
  • HA_MID: medium-priority high-reliability tasks, such as migration tasks
  • COMPACTION_LOW: major merge tasks
  • HA_LOW: low-priority high-reliability tasks such as backup and backup cleanup
  • DDL: tasks in scenarios such as unique index verification and data completion upon column deletion
  • DDL_HIGH: dump tasks for DDL MemTable
  • CLOG_LOW: physical standby and CDC read tasks
  • CLOG_MID: tasks such as Follower replica reading from shared storage and log archive reading from local disk
  • CLOG_HIGH: tasks such as clog writing to local disk, clog file upload to shared storage, and Follower replica reading from local disk
  • OPT_STATS: statistics collection tasks
  • GC_MACRO_BLOCK: macro block recycling and reuse tasks
  • SQL_AUDIT: SQL audit log persistence
  • IMPORT: import tasks
  • MVIEW: materialized view background tasks (supported from V4.3.5 BP2 for V4.3.5)
  • REPLAY_HIGH: log replay tasks (supported from V4.3.5 BP2 for V4.3.5)