This topic describes the concepts and categories of resource isolation.
Control groups (cgroups) are a mechanism provided by the Linux kernel that allows a series of system tasks and their subtasks to be grouped (or separated) into different resource-level groups based on specific behaviors. This provides a unified framework for system resource management.
In OceanBase Database, resource isolation can be categorized into global resource isolation, inter-tenant resource isolation, and intra-tenant resource isolation based on the level of isolation.
Global Resource Isolation
Global resource isolation manages the CPU resource usage of foreground and background tasks for all user tenants at the cluster level. By uniformly limiting the CPU usage of background tasks for all user tenants, this feature prevents background tasks from impacting the performance of foreground business operations. For detailed configuration methods on global resource isolation, see Isolation of foreground and background processes using global CPU resources.
Resource isolation between tenants
When you create a tenant, the system tenant assigns unit specifications to the user tenant. Resource isolation between tenants is controlled by these unit specifications. The isolated resources include CPU, memory, disk space, and IOPS.
The MAX_CPU and MIN_CPU values in the unit specifications of each tenant determine the CPU resource isolation strategy. The MAX_IOPS, MIN_IOPS, and IOPS_WEIGH values in the unit specifications of each tenant determine the IOPS resource isolation strategy.
Resource isolation within a tenant
Resource isolation within a tenant is primarily achieved through the DBMS_RESOURCE_MANAGER system package, which controls the tenant's CPU and IOPS resource usage.
Overview of the DBMS_RESOURCE_MANAGER package
OceanBase Database manages resource allocation within the database through the PL's DBMS_RESOURCE_MANAGER system package, thereby achieving resource isolation. The DBMS_RESOURCE_MANAGER system package is primarily used to maintain the following elements:
Resource groups: A group of sessions that are combined based on resource requirements. The system allocates resources to a resource group rather than to individual sessions.
Resource management plan: A container for resource management plan content, specifying how resources are allocated to resource groups. You can control resource allocation by activating a specific resource management plan. One resource management plan can contain multiple rules. However, a resource management plan must not contain two identical rules.
Resource management plan: Associates a resource group with a resource management plan and specifies how resources are allocated to the resource group.
For more information about the DBMS_RESOURCE_MANAGER system package, see DBMS_RESOURCE_MANAGER system package (Oracle-compatible mode). and the DBMS_RESOURCE_MANAGER system package (MySQL-compatible mode).
Resource isolation methods
When configuring resource isolation within a tenant using the DBMS_RESOURCE_MANAGER system package, the isolation can be categorized based on the granularity of resource allocation as follows:
User-level resource isolation
User-level resource isolation is achieved by specifying the mapping between users and resource groups, so that all SQL statements executed by a user use resources allocated to the corresponding group.
SQL-level resource isolation
SQL-level resource isolation provides a finer granularity than user-level isolation. It is implemented by binding SQL statements that meet certain conditions to specified resource groups for execution. This approach is typically suitable in scenarios where multiple accounts exist in the business. When processing an order for one account, a transaction is started and a batch of SQL statements related to that account are executed (usually by specifying the account value in the WHERE clause). An account may consist of large accounts (with larger data volumes) and small accounts (with smaller data volumes). To prevent large accounts from consuming all CPU resources and preventing small accounts' orders from being processed, SQL statements for different orders can be bound to different resource groups. After binding, the SQL statements for different orders will use the resources of their respective resource groups.
Function-level resource isolation
Function-level resource isolation isolates the resources used by each task by specifying the mapping relationship between background tasks and resource groups. Function-level resource isolation is used to control the CPU and IOPS usage of background tasks.
Currently, it supports controlling the resource usage of the following types of background tasks corresponding to DAG threads:
- COMPACTION_HIGH: Mini Merge and DDL KV Merge tasks
- HA_HIGH: High-priority and high-reliability tasks such as replication, Rebuild, and recovery
- COMPACTION_MID: Minor Merge tasks
- HA_MID: Medium-priority and high-reliability tasks, such as migration tasks
- COMPACTION_LOW: Major Merge tasks
- HA_LOW: Low-priority and high-reliability tasks such as backup and backup cleanup
- DDL: Tasks for scenarios such as unique index verification and data replenishment after column deletion
- DDL_HIGH: DDL MemTable minor compaction tasks
- CLOG_LOW: Physical standby database and CDC read tasks
- CLOG_MID: Log archiving reads from local disks, etc.
- CLOG_HIGH: clog writes to local disks, Follower replica reads from local disks, etc.
- OPT_STATS: Statistics collection tasks
- GC_MACRO_BLOCK: Macroblock recycling and reuse tasks
- SQL_AUDIT: SQL audit log persistence to disk
- IMPORT: Import tasks
- MVIEW: Materialized view background tasks (for V4.3.5, supported starting from V4.3.5 BP2)
- REPLAY_HIGH: Log replay (for V4.3.5, supported starting from V4.3.5 BP2)
Database-level resource isolation
Note
- In OceanBase Database, only the MySQL-compatible mode supports database-level resource isolation; the Oracle-compatible mode does not support it.
- The database-level resource isolation switch is controlled by the tenant-level hidden parameter
_enable_database_isolation_mode. Its default value isFalse, which means database-level resource isolation is disabled. If you need to modify the parameter value, the change takes effect only after a restart.
Database-level resource isolation binds specific databases to resource groups to isolate resources for all requests on that database.
