Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

Multi-tenancy

Updated on 2025-02-12 GMT+08:00

This section describes the syntax and usage of multi-tenant data isolation and resource isolation provided by TaurusDB.

Overview

TaurusDB provides multi-tenancy to maximize database resource utilization. Data is isolated among tenants. Different tenants can only access their own data. There are tenant-level resource isolation and user-level resource isolation to avoid resource wastes and improve performance. Resources can be dynamically adjusted to process workload peaks and troughs of different tenants or users in a timely manner.

The following figure shows the principle of multi-tenancy.

Figure 1 Principle diagram

Basic Concepts

Table 1 describes the terms for tenant-level and user-level resource isolation.

Table 1 Term description

Level

Term

Tenant-level

tenant: Tenants are under a DB instance and above databases and users. Tenants are used for data isolation and resource isolation. However, databases can be accessed as a user.

resource configuration (resource_config): A resource configuration indicates the resources available to a tenant, enabling tenant-level resource isolation. Currently, vCPU resources can only be limited by setting min_cpu and max_cpu. The following resource configurations are built in:

  • RDS_SYS_CONFIG: resource configuration of the system tenant. The default value of min_cpu is 0.1 (unit: vCPUs), and the default value of max_cpu is the vCPUs in the instance specifications.
  • shared_tenants_config: resource configuration of the shared tenant. The value of min_cpu is fixed to 0, and the default value of max_cpu is the vCPUs in the instance specifications.

There are system tenants and common tenants based on data isolation.

system tenant (sys_tenant): System tenants are designed to accommodate users that exist before the implementation of multi-tenancy. By default, these existing users belong to system tenants and are also referred to as system users. If a user under a system tenant can connect to and access a DB instance, the user can access the databases of all tenants.

common tenant (user_tenant): You can create common tenants as a system tenant. The users and databases of each common tenant are completely isolated from those of other common tenants. In addition, common tenants cannot access databases of the system tenants.

The resources available to tenants, currently limited to vCPUs, are determined by tenant-level resource configurations. There are dedicated tenants and shared tenants based on resource isolation.

dedicated tenant: The value of min_cpu in the resource configuration associated with the tenant is greater than 0. Ensure that vCPUs allocated to dedicated tenants at any time are not less than the value of min_cpu.

shared tenant: tenants associated with the specific resource configuration shared_tenants_config. The value of min_cpu in the resource configuration is 0. The system preferentially ensures the resource requests of dedicated tenants and then allocates the remaining resources to shared tenants. In addition, the system reserves some vCPUs (specified by the mt_shared_cpu_reserved parameter) for shared tenants to ensure that shared tenants can obtain resources during vCPU contention. You can modify associated resource configurations to change the roles between dedicated and shared tenants.

User-level

Users are under DB instances and tenants. A tenant can have multiple users. Multi-tenancy does not change how user data is isolated, but it does provide a way to manage resources at the user level.

Figure 2 User-level resource configuration relationship

resource consumer group (consumer_group)

Multiple users can belong to a given resource consumer group to share the resources associated with the group.

resource plan directive (plan_directive)

A resource plan directive corresponds to only one resource consumer group and describes the specific resource configuration of the resource consumer group. A resource consumer group can be associated with multiple resource plan directives, but only one can be enabled at a time.

resource plan (plan)

A resource plan controls whether to enable or disable a resource plan directive. Each resource plan is associated with one or more resource plan directives. Enabling or disabling a resource plan will activate or deactivate the resource plan directive. Only one resource plan can be enabled per tenant.

Constraints

  • Multi-tenancy can only isolate tenant data, tenant vCPUs, and user vCPUs.
  • The kernel version of your TaurusDB instance must be 2.0.57.240900 or later.
  • Thread Pool must be enabled.
  • Database names, usernames, and tablespace names in a DB instance do not contain at signs (@).
  • Serverless instances do not support multi-tenancy.
  • If the kernel version of your TaurusDB instance is 2.0.60.241200 or later, the new multi-tenant views (including MT_RESOURCE_CONFIG, MT_TENANT, MT_TENANT_DB, MT_RESOURCE_PLAN, MT_CONSUMER_GROUP, MT_GROUP_MAPPING_RULE, and MT_PLAN_DIRECTIVE) will replace the old DBA_RSRC_* views.
  • Binlog:

    If common tenants pull binlogs, data among tenants will not be isolated. Users of common tenants are not allowed to pull binlogs.

  • Proxy instance:

    The HTAP standard and lightweight editions do not support databases whose name contains at signs (@). When a database of a common tenant is migrated to an HTAP instance, the destination database name will be changed. After Auto Assign Requests to Column Store or Row Store Nodes is enabled, the proxy instance requires that the source and destination database names be the same, so this function must be disabled for migrating databases of common tenants.

  • Backup and restoration:

    When you restore data of an instance with multi-tenancy enabled to a new instance with multi-tenancy disabled, you cannot create users, databases, and tablespaces with at signs (@) in their names for the new instance.

  • Upgrade and downgrade:
    • If the kernel version of your TaurusDB instance with multi-tenancy enabled is downgraded from 2.0.60.241200 or later to a version earlier than 2.0.60.241200, multi-tenancy will be disabled. To re-enable the function, you need to reboot the instance.
    • If the kernel version of your TaurusDB instance is downgraded from 2.0.60.241200 or later to a version earlier than 2.0.60.241200, the new multi-tenant views (including MT_RESOURCE_CONFIG, MT_TENANT, MT_TENANT_DB, MT_RESOURCE_PLAN, MT_CONSUMER_GROUP, MT_GROUP_MAPPING_RULE, and MT_PLAN_DIRECTIVE) may still be displayed when you run the show tables command in information_schema, but cannot be accessed. To clear the residual multi-tenant view metadata, you need to reboot the instance.
    • If the kernel version of your TaurusDB instance is upgraded to 2.0.60.241200 or later, the new multi-tenant views may fail to be displayed when you run the show tables command in information_schema, but can be accessed. To display the multi-tenant views, you need to reboot the instance.
  • Compatibility:
    • If multi-tenancy is enabled and then disabled, the names of databases, users, or tablespaces cannot contain at signs (@).
    • For a common tenant, the maximum length of a database name is reduced from 64 characters to 50 characters, and the maximum length of a user name is reduced from 32 characters to 20 characters.
    • The system databases mysql and sys are not available to common tenants.
    • For a common tenant, fuzzy search is required when a username or database name is used to query tables in the system database performance_schema.
    • User root under a system tenant can kill sessions of other users. Users under a common tenant can only kill their own sessions.
    • Instances with multi-tenancy enabled do not support full-text indexes.

Enabling Multi-tenancy

  1. Log in to the management console.
  2. Click in the upper left corner and select a region and project.
  3. Click in the upper left corner of the page and choose Databases > TaurusDB.
  4. On the Instances page, click the instance name to go to the Basic Information page.
  5. In the Instance Information area, click under Multi-tenancy. In the displayed dialog box, click OK.

    Before enabling multi-tenancy, ensure that the existing database names, usernames, and tablespaces do not contain at signs (@), or the function fails to be enabled.

Resource Management

Resource configurations and tenants are in one-to-many relationship. When a tenant is bound to a resource configuration, the vCPUs used by users of the tenant is restricted.

  • Create a resource configuration.
    CREATE resource_config config_name MAX_CPU [=] {max_cpu_value} [MIN_CPU [=] {min_cpu_value}];
  • Alter a resource configuration.
    ALTER resource_config config_name MAX_CPU [=] {max_cpu_value} [MIN_CPU [=] {min_cpu_value}];
  • Drop a resource configuration.
    DROP resource_config config_name;
  • Query a resource configuration.
    SELECT * FROM information_schema.DBA_RSRC_TENANT_RESOURCE_CONFIGS;
NOTE:
  • The proceeding statements can only be executed by user root.
  • Parameter description:
    • config_name: resource configuration name. The value can contain up to 64 characters. Only uppercase letters, lowercase letters, digits, and underscores (_) are allowed.
    • MAX_CPU: maximum vCPUs available to tenants bound to a resource configuration. The minimum value is 0.1, and the maximum value is vCPUs in the instance specifications. You can obtain the value from the mt_flavor_cpu variable. The granularity is 0.1.
    • MIN_CPU: vCPUs committed to tenants bound to a resource configuration during vCPU contention. This parameter is optional. The default value is the same as the value of MAX_CPU. Value range: 0.1 to the value of MAX_CPU. The granularity is 0.1. (Note: shared_tenants_config is a built-in resource configuration, and its MIN_CPU is 0.) vCPUs committed to tenants comply with an on-demand allocation policy and are not reserved. For example, if 1 vCPU is committed to a tenant but only 0.3 vCPU is required due to small workloads, the remaining 0.7 vCPU will be allocated to other tenants as needed.
  • When a resource configuration is updated, if it has been bound to a tenant and the updated MIN_CPU value is greater than the original MIN_CPU value, check whether the new value meets the resource constraints, or the resource constraints are not verified.
  • If a tenant is using a resource configuration, the resource configuration cannot be deleted.
  • During vCPU contention, resources are allocated to tenants based on the value of MIN_CPU specified for each tenant. However, there is a certain error, which is usually within 1 vCPU.
  • The peak instance read/write performance for each tenant is not directly proportional to the allocated vCPUs. For example, if you allocate an instance with 16 vCPUs to two tenants, each with a maximum of 8 vCPUs, the combined TPS when both tenants are running at full capacity will not be twice the performance of an instance with 8 vCPUs. That is, among two instances with the same specifications, the instance with multi-tenancy enabled delivers slightly lower performance than that with multi-tenancy disabled.

Tenant Management

When creating a tenant, you need to bind it to a resource configuration to restrict vCPUs used by users under the tenant.

  • Create a tenant.
    CREATE TENANT tenant_name RESOURCE_CONFIG config_name [COMMENT [=] 'comment_string'];
  • Alter a tenant.
    ALTER TENANT tenant_name RESOURCE_CONFIG config_name [COMMENT [=] 'comment_string'];
  • Drop a tenant.
    DROP TENANT tenant_name;
  • Query a tenant.
    SELECT * FROM information_schema.DBA_RSRC_TENANT;
NOTE:
  • The proceeding statements can only be executed by user root.
  • Creating a tenant:
    • The value of tenant_name can contain up to 10 characters. Only lowercase letters, digits, and underscores (_) are allowed.
    • When a tenant is created, the system checks resource constraints to ensure that the sum of the MIN_CPU values in the resource configurations of all tenants meets the resource constraints.
    • If a tenant is bound to shared_tenants_config, the tenant is a shared tenant. Otherwise, the tenant is a dedicated tenant. During resource contention, resources are first allocated to dedicated tenants based on the value of MIN_CPU. Any remaining resources are then contested by both shared and dedicated tenants.
    • Resources between tenants are fully utilized.

      For example, there is an instance with 8 vCPUs. The MIN_CPU and MAX_CPU allocated to tenant A are 3 vCPUs and 8 vCPUs, respectively. The MIN_CPU and MAX_CPU allocated to tenant B are 5 vCPUs and 8 vCPUs, respectively. If tenant A uses 0 vCPUs, tenant B can use 8 vCPUs. If tenant A uses 1 vCPU, tenant B can use 7 vCPUs.

  • Altering a tenant:
    • If the MIN_CPU value of the newly bound resource configuration is at least that of the original resource configuration, the system checks the resource constraints. Ensure that the sum of the MIN_CPU values in the resource configurations of all tenants meets the resource constraints.
    • If a dedicated tenant is bound to shared_tenants_config, the tenant becomes a shared tenant and any user-level resource isolation configurations under the tenant are deleted.
  • Dropping a tenant:
    • Before dropping a tenant, you need to ensure that the databases and users of the tenant have been deleted, or the tenant cannot be deleted.
    • When a tenant is deleted, user-level resource isolation configurations associated with the tenant are also deleted.

User Management

After multi-tenancy is enabled, there are users of system tenants and users of common tenants. Existing users belong to system tenants. New users can belong to system tenants or common tenants based on the interface semantics.

  • Managing users under a system tenant

    Creating a user

    Create a user for a system tenant.

    CREATE user [IF NOT EXISTS] user_name@'host';

    Create a user for a common tenant.

    CREATE user [IF NOT EXISTS] 'user_name@tenant_name'@'host'; 

    Renaming a user

    Rename a user under a system tenant.

    RENAME USER user_from@host1 TO user_to@'host'; 

    Rename a user under a common tenant.

    RENAME USER 'user_from@tenant_name'@host1 TO 'user_to@tenant_name'@'host'; 

    Dropping a user

    Drop a user under a system tenant.

    DROP USER [IF EXISTS] user_name@'host'; 

    Drop a user under a common tenant.

    DROP USER [IF EXISTS] 'user_name@tenant_name'@'host';

    Authorizing a user

    Grant the priv_type permissions of tenant_1 to 'user_1@tenant_1'@'%'.

    GRANT priv_type ON *.* to 'user_1@tenant_1'@'%' with grant option;

    View permissions.

    SHOW grants for 'user_1@tenant_1'@'%';
  • Managing users under a common tenant

    Creating a user

    Create a user for the current tenant.

    CREATE user [IF NOT EXISTS] user_name@'host'; 

    Renaming a user

    RENAME USER user_from@host1 TO user_to@'host';

    Dropping a user

    DROP USER [IF EXISTS] user_name@'host';

    Authorizing a user

    Grant the priv_type permissions of the current tenant to user1.

    GRANT priv_type ON *.* to 'user_1'@'%' with grant option;

    View permissions.

    SHOW grants for 'user_1';
NOTE:
  • When creating or dropping a user of a common tenant as a system tenant, you need to use the user_name@tenant_name format.
  • Usernames under a common tenant can contain a maximum of 20 characters.
  • Some special users cannot be created under a tenant, including mysql.sys, mysql.session, mysql.infoschema, and users reserved in the rds_reserved_users parameter.
  • When renaming a user of a common tenant as a system tenant, ensure that the values of tenant_name in user_from and user_to are the same, or an error is returned.
  • When multi-tenancy is disabled, users under common tenants cannot be renamed.

Database Management

There are databases of system tenants and databases of common tenants. System tenants can access all databases, and common tenants can only access their own databases.

  • Managing databases as a system tenant

    Creating a database

    Create a database for a system tenant.

    CREATE DATABASE [IF NOT EXISTS] `db_name`;

    Create a database for a common tenant.

    CREATE DATABASE [IF NOT EXISTS] `db_name@tanant_name`; 

    Dropping a database

    Drop a database of a system tenant.

    DROP DATABASE [IF EXISTS] `db_name`;

    Drop a database of a common tenant.

    DROP DATABASE [IF EXISTS] `db_name@tanant_name`;
  • Managing databases as a common tenant

    Create a database for the current tenant.

    CREATE DATABASE [IF NOT EXISTS] 'db_name'; 

    Drop a database of the current tenant.

    DROP DATABASE [IF EXISTS] 'db_name';
NOTE:
  • Under a system tenant, you need to perform operations on databases of a common tenant in db_name@tenant_name mode.
  • The system databases SYS and MYSQL cannot be accessed by common tenants.
  • Some special databases, such as INFORMATION_SCHEMA, PERFORMANCE_SCHEMA, MYSQL, SYS, and __recyclebin__, cannot be created in a tenant.
  • Allocating existing databases to tenants

    To ensure compatibility after an upgrade or migration to an instance with multi-tenancy enabled, existing databases are under system tenants by default. You can allocate the existing databases to specified tenants. Additionally, after multi-tenancy is enabled, you can allocate databases that are created by system tenants and are not allocated to common tenants to specified tenants.

    Allocating a database

    Allocate a database to common tenant tenant_name.

    ALTER DATABASE db_name TENANT = `tenant_name`;

    Allocate a database back to a system tenant.

    ALTER DATABASE db_name TENANT = ``;

    Querying the mappings

    SELECT * FROM information_schema.DBA_RSRC_TENANT_DB;
    NOTE:
    • The proceeding statements can only be executed by user root.
    • If a database is created after multi-tenancy is enabled and named in the format of db_name@tenant_name, it cannot be allocated using the database allocation statements. Otherwise, an error will be returned.
    • If you specify a non-existent tenant in the statements, an error will be returned.
  • Connecting to a database as a user of a tenant

    Under a system tenant, the original connection mode remains unchanged.

    Under a common tenant, the user must be in the format of user_name@tenant_name. The database must be in the format of db_name or db_name@tenant_name.

    mysql --host=**** -u user1@tenant_1 -D db1 -p password;
    mysql --host=**** -u user1@tenant_1 -D db1@tenant_1 -p password;

    After the connection is successful, the user is restricted by the resources of the corresponding tenant.

Tablespace Management

Tenant isolation is implemented for general tablespaces. There are two types of tablespaces: those for system tenants and those for common tenants. System tenants can access all tablespaces, while common tenants can only access their own tablespaces. In upgrade and migration scenarios, existing tablespaces remain unchanged and belong to the system tenants.

  • Managing tablespaces as a system tenant
    • Creating a tablespace

      Create a tablespace for a system tenant.

      CREATE TABLESPACE `tablespace_name`;
      CREATE TABLESPACE `tablespace_name` add datafile `tablespace_file_name.ibd`;

      Create a tablespace for a common tenant.

      CREATE TABLESPACE `tablespace_name@tenant_name`;
      CREATE TABLESPACE `tablespace_name@tenant_name` add datafile `tablespace_file_name.ibd`;
    • Dropping a tablespace

      Drop a tablespace of a system tenant.

      DROP TABLESPACE `tablespace_name`;

      Drop a tablespace of a common tenant.

      DROP TABLESPACE `tablespace_name@tenant_name`;
    • Renaming a tablespace

      Rename a tablespace of a system tenant.

      ALTER TABLESPACE `tablespace_name` RENAME TO `tablespace_name`;

      Rename a tablespace of a common tenant.

      ALTER TABLESPACE ` tablespace_name@tenant_name ` RENAME TO `new_tablespace_name@tenant_name`;
    • Associating a table with a tablespace

      Create a table for a system tenant and associate it with a specified tablespace.

      CREATE TABLE table_name ... TABLESPACE [=] `tablespace_name`;

      Create a table for a common tenant and associate it with a specified tablespace.

      CREATE TABLE table_name ... TABLESPACE [=] `tablespace_name@tenant_name`;

      Associate an existing table of a system tenant with a specified tablespace.

      ALTER TABLE table_name TABLESPACE `tablespace_name`;

      Associate an existing table of a common tenant with a specified tablespace.

      ALTER TABLE table_name TABLESPACE `tablespace_name@tenant_name`;
  • Managing tablespaces as a common tenant
    • Create a tablespace for the current tenant.
      CREATE TABLESPACE `tablespace_name`;
    • Drop a tablespace of the current tenant.
      DROP TABLESPACE `tablespace_name`;
    • Rename a tablespace of the current tenant.
      ALTER TABLESPACE `tablespace_name` RENAME TO ` tablespace_name `;
    • Create a table for the current tenant and associate it with a specified tablespace.
      CREATE TABLE table_name ... TABLESPACE [=] tablespace_name;
    • Associate an existing table of the current tenant with a specified tablespace.
      ALTER TABLE table_name TABLESPACE `tablespace_name`;
      NOTE:
      • After multi-tenancy is enabled, the maximum length of a tablespace name allowed is reduced from 64 characters to 50 characters, and the tablespace name cannot contain any at signs (@).
      • You cannot create special tablespaces, such as those that start with innodb_.
      • If a tenant attempts to create a tablespace with the same datafile name as one created by themselves or another tenant, the tablespace will fail to be created.
      • If you plan to associate a common tenant's table with a tablespace starting with innodb_ (a system tablespace) as a system tenant, you can omit @tenant_name after tablespace_name in the command.
      • If you plan to associate a common tenant's table with a common tenant's tablespace as a system tenant, the table and tablespace must belong to the same tenant.

User-level Resource Configurations

By default, users under a tenant share the resources of the tenant. To restrict user-level resources, you can call the API in this section.

CAUTION:

User-level resource configurations are unavailable to shared tenants.

  • Managing resource consumer groups (consumer_group)

    Multiple users can belong to a given resource consumer group and they share the resources associated with the resource consumer group. Users under a tenant can connect to a database to manage resource consumer groups.

    Creating a consumer group

    dbms_resource_manager.create_consumer_group (
       consumer_group     CHAR(128),
       comment            CHAR(2000));
    NOTE:
    • consumer_group: name of the resource consumer group. Only uppercase letters, lowercase letters, digits, and underscores (_) are allowed.
    • comment: description of the resource consumer group. The value can be ''.

    Adding a user to a resource consumer group/Removing a user from a resource consumer group

    dbms_resource_manager.set_consumer_group_mapping ( 
       attribute        CHAR(128),  
       value            varbinary(128),  
       consumer_group   CHAR(128));
    NOTE:
    • attribute: mapping attribute to be added or modified. The current version supports only USER.
    • value: mapping attribute to be added or modified. The current version supports only usernames.
    • consumer_group: name of the resource consumer group. If this parameter is not empty, users are added to the resource consumer group. If this parameter is empty (''), users are removed from the resource consumer group.

    Deleting a consumer group

    dbms_resource_manager.delete_consumer_group (
        consumer_group   CHAR(128));
    NOTE:
    • consumer_group: name of the resource consumer group.
    • When a resource consumer group is deleted, the resource plan directive and resource consumer group mapping corresponding to the resource consumer group are also deleted.
    • If multi-tenancy is enabled, deleted users will be automatically removed from their associated resource consumer groups. If multi-tenancy is disabled, deleted users will remain in their associated resource consumer groups. However, if multi-tenancy is later enabled, the system will remove these deleted users from their resource consumer groups.
    • If multi-tenancy is enabled, the mapping between a user and a resource consumer group is not affected when the user is renamed. If you delete a user and create a user with the same name after multi-tenancy is disabled, the user still belongs to the original resource consumer group after the multi-tenancy is enabled.

    Viewing resource consumer groups

    The DBA_RSRC_CONSUMER_GROUPS view records information about resource consumer groups. If you are under a system tenant, you can view the resource consumer groups of all tenants. If you are under a common tenant, you can only view the resource consumer groups of the current tenant.

    select * from information_schema.DBA_RSRC_CONSUMER_GROUPS;

    Viewing the mappings between users and resource consumer groups

    The DBA_RSRC_GROUP_MAPPINGS view records the mappings between users and resource consumer groups. If you are under a system tenant, you can view the mappings between users and resource consumer groups of all tenants. If you are under a common tenant, you can only view the mappings between users and resource consumer groups of the current tenant.

    select * from information_schema.DBA_RSRC_GROUP_MAPPINGS;

Resource Plan Management

A resource plan is used to enable or disable resource plan directives. Each resource plan is associated with one or more resource plan directives. Enabling or disabling a resource plan will activate or deactivate the corresponding resource plan directives. Only one resource plan can be enabled per tenant.

  • Create a resource plan.
    dbms_resource_manager.create_plan (
       plan_name         VARCHAR(128), 
       comment           VARCHAR(2000));
    NOTE:
    • plan_name: resource plan name. Only uppercase letters, lowercase letters, digits, and underscores (_) are allowed.
    • comment: description of the resource plan. The value can be ''.
    • If you delete an enabled resource plan, it will be left empty and its associated resource plan directives will be deleted.
    • mt_resource_plan_num: number of plans. By default, there are up to 128 plans.
  • Enable or disable a resource plan.
    dbms_resource_manager.set_resource_manager_plan( 
        plan_name     VARCHAR(128));
    NOTE:
    • plan_name: resource plan name. If the value is empty (''), the resource plan is disabled.
  • Delete a resource plan.
    dbms_resource_manager.delete_plan (
        plan_name    VARCHAR(128));
    NOTE:
    • plan_name: resource plan name.
    • If you delete an enabled resource plan, the resource plan configuration will be cleared and any associated resource plan directives will also be deleted.
  • Query a resource plan.

    The DBA_RSRC_PLANS view records details about resource plans. If you are under a system tenant, you can view the resource plans of all tenants. If you are under a common tenant, you can only view the resource plans of the current tenant.

    SELECT * FROM information_schema.DBA_RSRC_PLANS;

Resource Plan Directive Management

A resource plan directive corresponds to only one resource consumer group and describes the specific resource configuration of the resource consumer group. A resource consumer group can be associated with multiple resource plan directives, but only one can be enabled at a time. As mentioned earlier, you can enable a resource plan directive by enabling a resource plan.

  • Creating a resource plan directive
    dbms_resource_manager.create_plan_directive (
       plan                    CHAR(128), 
       group_or_subplan        CHAR(128), 
       comment                 VARCHAR(2000), 
       mgmt_p1                 bigint(20),
       utilization_limit       bigint(20));
    NOTE:
    • plan: resource plan name.
    • group_or_subplan: name of the resource consumer group.
    • comment: description of the resource plan directive. The value can be ''.
    • mgmt_p1: percentage of total vCPUs of a tenant that is vCPUs committed to the resource consumer group in the case of vCPU contention. The value range is [0, 100] (100: 100% vCPUs of the tenant are used). The sum of mgmt_p1 of all resource plan directives associated with a resource plan of a tenant cannot exceed 100. In the event of vCPU contention among resource consumer groups of a tenant, the vCPUs committed to each resource consumer group are preferentially allocated based on an on-demand allocation policy, and the remaining vCPUs are contested by each resource consumer group. For example, if 20% vCPUs are committed to a resource consumer group but only 5% vCPUs are required due to small workloads, the remaining 15% vCPUs will be allocated to other resource consumer groups as needed.
    • utilization_limit: upper limit on CPU utilization for a resource consumer group. The value range is [1, 100]. The value 100 indicates that a group can use all vCPUs of the tenant. The value 70 indicates that it can only use 70% vCPUs of the tenant.
    • Users in a resource consumer group share the resources configured by the enabled resource plan directive. For example, if user1 and user2 of a tenant are added to consumer_group1, the utilization_limit value of the enabled resource plan directive for consumer_group1 is 70, and the mgmt_p1 value is 10, then user1 and user2 can use up to 70% vCPUs of the tenant. During vCPU contention, the total vCPUs that are committed to user1 and user2 are 10% vCPUs of the tenant.
  • Updating a resource plan directive
    dbms_resource_manager.update_plan_directive (
       plan                    CHAR(128), 
       group_or_subplan        CHAR(128), 
       new_comment             VARCHAR(2000), 
       new_mgmt_p1             bigint(20),
       new_utilization_limit   bigint(20));
    NOTE:
    • plan: resource plan name.
    • group_or_subplan: name of the resource consumer group.
    • comment: description of the resource plan directive. The value can be ''.
    • mgmt_p1: percentage of total vCPUs of a tenant that is vCPUs committed to the resource consumer group in the case of vCPU contention. The value range is [0, 100] (100: 100% vCPUs of the tenant are used). The sum of mgmt_p1 of all resource plan directives associated with a resource plan of a tenant cannot exceed 100. In the event of vCPU contention among resource consumer groups of a tenant, the vCPUs committed to each resource consumer group are preferentially allocated based on an on-demand allocation policy, and the remaining vCPUs are contested by each resource consumer group. For example, if 20% vCPUs are committed to a resource consumer group but only 5% vCPUs are required due to small workloads, the remaining 15% vCPUs will be allocated to other resource consumer groups as needed.
    • utilization_limit: upper limit on CPU utilization for a resource consumer group. The value range is [1, 100]. The value 100 indicates that a group can use all vCPUs of the tenant. The value 70 indicates that it can only use 70% vCPUs of the tenant.
    • Users in a resource consumer group share the resources configured by the enabled resource plan directive. For example, if user1 and user2 of a tenant are added to consumer_group1, the utilization_limit value of the enabled resource plan directive for consumer_group1 is 70, and the mgmt_p1 value is 10, then user1 and user2 can use up to 70% vCPUs of the tenant. During vCPU contention, the total vCPUs that are committed to user1 and user2 are 10% vCPUs of the tenant.
  • Deleting a resource plan directive
    dbms_resource_manager.delete_plan_directive (
        plan                   CHAR(128), 
        group_or_subplan       VARCHAR(128));
    NOTE:
    • plan: resource plan name.
    • group_or_subplan: name of the resource consumer group.
    • If you delete a resource plan directive that has been enabled, the resource configuration of the corresponding user will become invalid.
  • Querying a resource plan directive

    The DBA_RSRC_PLAN_DIRECTIVES view records details about resource plan directives. If you are under a system tenant, you can view the resource plan directives of all tenants. If you are under a common tenant, you can only view the resource plan directives of the current tenant.

    SELECT * FROM information_schema.DBA_RSRC_PLAN_DIRECTIVES;

User-level Configuration Clearing

You can clear all user-level resource configurations of a tenant, including resource consumer groups, resource plans, and resource plan directives. If you execute this statement under a system tenant, only the user-level resource configurations of the system tenant are cleared.
dbms_resource_manager.clear_all_configs();

vCPU Usage Statistics

  • User-level vCPU usage

    The information_schema.cpu_summary_by_user view is added to display the vCPU usage of each resource consumer group. If you are under a system tenant, you can view the vCPU usage of resource consumer groups of all tenants. If you are under a common tenant, you can only view the vCPU usage of resource consumer groups of the current tenant.

    SELECT * FROM information_schema.cpu_summary_by_user;
    NOTE:
    • The column names in the query result are described as follows:

      TENANT_NAME: name of the tenant the user belongs to.

      CONSUMER_GROUP: name of the resource consumer group.

      CPU_USAGE: vCPU usage of the resource consumer group, that is, the ratio of the used vCPUs to the total vCPUs of the instance. For example, if an instance has 4 vCPUs and a resource consumer group uses 2 vCPUs, the value of CPU_USAGE is 50%.

      CPU_USAGE_RELATIVE: relative vCPU usage of the resource consumer group, that is, the ratio of the used vCPUs to the MAX_CPU value configured for the tenant. For example, if the MAX_CPU value configured for a tenant is 4 and a resource consumer group actually uses 2 vCPUs, the value of CPU_USAGE_RELATIVE is 50%.

      INCLUDED_USERS: names of the users bound to the resource consumer group.

    • A default resource consumer group default_group is created for a dedicated tenant. Under the dedicated tenant, all users who are not bound to a specific resource consumer group belong to default_group. By default, default_group can use all vCPUs of the tenant. In the event of vCPU contention within the tenant, the vCPUs committed to other resource consumer groups are preferentially allocated, and the remaining vCPUs are allocated to default_group.
  • Tenant-level vCPU usage

    The information_schema.cpu_summary_by_tenant view is added to display the vCPU usage of each tenant. If you are under a system tenant, you can view the vCPU usage of all tenants. If you are under a common tenant, you can only view the vCPU usage of the current tenant.

    SELECT * FROM information_schema.cpu_summary_by_tenant;
    NOTE:
    • The column names in the query result are described as follows:

      TENANT_NAME: tenant name.

      TENANT_TYPE: tenant type. Value exclusive indicates a dedicated tenant, and value shared indicates a shared tenant.

      CPU_USAGE: vCPU usage of the tenant, that is, the ratio of the used vCPUs to the total vCPUs of the instance. For example, if an instance has 4 vCPUs and a tenant uses 2 vCPUs, the value of CPU_USAGE is 50%.

      CPU_USAGE_RELATIVE: relative vCPU usage of the tenant, that is, the ratio of the vCPUs used by the tenant to the MAX_CPU value. For example, if the MAX_CPU value configured for a tenant is 4 and the tenant actually uses 2 vCPUs, the value of CPU_USAGE is 50%.

    • After MIN_CPU of all dedicated tenants are ensured, the remaining vCPUs are shared among all shared tenants. In the view, the CPU usage for each shared tenant is displayed as the sum of the CPU usage of all shared tenants.

Data Migration Using DRS

After multi-tenancy is enabled, you can migrate data of all tenants using DRS.

If the kernel version of your TaurusDB instance is earlier than 2.0.60.241200, DRS does not synchronize tenant metadata. It means that tenant information will not be synchronized to the destination instance. To migrate a tenant from one instance to another, perform the following steps:

  1. Select an instance that supports multi-tenancy as the destination instance and manually create a tenant for the destination instance.
  2. Use DRS to create a database-level synchronization task. (If the tenant names at the source and destination instances are changed, you need to change the destination database name.)

  3. Synchronize data.

If the kernel version of your TaurusDB instance is 2.0.60.241200 or later, you can migrate tenant metadata across instances using DRS. To do this, simply create a database-level synchronization task.

CAUTION:
  • If the multi-tenancy setting of the source instance is inconsistent with that of the destination instance, the pre-check will fail.
  • If multi-tenancy is enabled for both the source and destination instances, you will receive a notification during the pre-check phase if there is a non-empty table in the __taurus_sys__ database because the multi-tenant metadata table contains the initial configurations. You can clear data in the non-empty table if needed. If the data is not cleared, it will be retained during DRS DR synchronization, which may cause multi-tenancy to be unavailable. The procedure for clearing data is as follows:
    1. Delete users, databases, and tablespaces of common tenants. Example:
      • Run select user,host from mysql.user where instr(user, '@') > 0 to check whether there are users under a common tenant. If there are, run drop user'user_name@tenant_name'@'%' to delete the users.
      • Run select * from SCHEMATA where instr(SCHEMA_NAME, '@') > 0 to check whether there are databases under a common tenant. If there are, run drop user 'db_name@tenant_name'@'%' to delete the databases.
      • Run select * from information_schema.MT_tenant_DB to query existing databases under a common tenant. Run alter database 'db_name' tenant = `` to reclaim the databases to a system tenant.
      • Run select * from information_schema.innodb_tablespaces where instr(NAME, '@') > 0 to query tablespaces created by a common tenant and run drop tablespace `tbs_name` to delete the tablespaces.
    2. Delete common tenants (user-level resource configurations will be automatically deleted) and the corresponding tenant-level resource configurations. Example:
      • drop tenant `tenant_name`;
      • drop resource_config config_name;
    3. Delete user-level resource configurations of system tenants. Example:

      CALL dbms_resource_manager.clear_all_configs();

  • If the source and destination instances have different versions or specifications, resource configurations of the source instance are not applied to the destination instance after the migration. You are advised to use the resource configuration syntax to adjust tenant resource configurations of the destination instance according to its specifications.
  • In DRS DR synchronization scenarios, do not use the IP address and port of the destination instance for migration. If you choose to use the IP address and port, tenant metadata cannot be migrated to the destination instance.

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback