Resource isolation overview

This topic describes the concepts, methods, and applicable scenarios of resource isolation.

Control Group (cgroup) is a Linux kernel feature that, based on specific behavior, aggregates or separates a set of system tasks and their subtasks into different groups by resource level, providing a unified framework for system resource management.

In the current version of OceanBase Database, tenant worker threads and most background threads are tenant-specific, while network threads are shared. After you configure the cgroup directory, you can use the DBMS_RESOURCE_MANAGER package to control the CPU and IOPS usage of tenants.

DBMS_RESOURCE_MANAGER system package

In OceanBase Database, the DBMS_RESOURCE_MANAGER system package of PL is used to manage resource allocation in the database to implement resource isolation. The DBMS_RESOURCE_MANAGER system package is used to maintain the following elements:

• Resource groups: 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 container of plan directives that specifies how resources are allocated to a resource group. You can activate a specific resource management plan to control resource allocation. A resource management plan can contain multiple plan directives. However, a resource management plan must not contain two identical plan directives.

• Plan directives: 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 system package (Oracle mode) and DBMS_RESOURCE_MANAGER system package (MySQL mode).

Resource isolation methods

When you configure resource isolation within a tenant by using the DBMS_RESOURCE_MANAGER system package, resource isolation can be classified into the following types by granularity:

• User-level resource isolation

  User-level resource isolation is implemented by specifying the mapping relationships between users and resource groups. This way, all SQL statements executed by the user use the resources allocated to the corresponding group.

• SQL-level resource isolation

  SQL-level resource isolation is finer-grained than user-level resource isolation. It is implemented by binding SQL statements that meet specific conditions to a specified resource group for execution. A typical scenario is a business with multiple accounts: processing an order for one account starts a transaction and runs a batch of SQL statements related to that account (usually by specifying the account value in the WHERE clause). Accounts may include large accounts (with more data) and small accounts (with less data). To prevent a large account from consuming all CPU resources and blocking order processing for small accounts, you can bind the SQL statements that handle different orders to different resource groups. After binding, SQL statements for different orders use resources from different resource groups.

• Function-level resource isolation

  Function-level resource isolation is implemented by specifying the mapping relationships between background tasks and resource groups to isolate the resources used by the tasks. Function-level resource isolation is used to control the CPU and IOPS resources used by background tasks.

  The following backend tasks corresponding to DAG threads are supported for resource control:

  • COMPACTION_HIGH: mini merge tasks and DDL key-value merge tasks
  • HA_HIGH: high-priority reliable tasks such as replication, rebuild, and recovery
  • COMPACTION_MID: minor merge tasks
  • HA_MID: medium-priority reliable tasks such as migration tasks
  • COMPACTION_LOW: major merge tasks
  • HA_LOW: low-priority reliable tasks such as backup and backup cleanup tasks
  • DDL: tasks such as unique index verification and column deletion with data supplementation
  • DDL_HIGH: tasks that perform minor compaction for DDL MemTables
  • CLOG_LOW: tasks such as physical standby database synchronization and CDC data reading
  • CLOG_MID: tasks such as follower replica's shared storage access and log archive reading from local disk
  • CLOG_HIGH: tasks such as clog writing to local disk and clog file uploading to shared storage, and follower replica's local disk access
  • OPT_STATS: statistics collection tasks
  • GC_MACRO_BLOCK: macro-block garbage collection and reuse tasks
  • SQL_AUDIT: SQL audit log writing to disk
  • IMPORT: import tasks
  • MVIEW: materialized view background tasks (supported starting from V4.3.5 BP2 in V4.3.5)
  • REPLAY_HIGH: log replay (supported starting from V4.3.5 BP2 in V4.3.5)