Multi-tenant Management and Resource Isolation

Overview

TaurusDB provides multi-tenant management 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-tenant management.

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 the multi-tenant management. 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-tenant management and resource isolation 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-tenant management and resource isolation.
• Tenant migration across instances:
  After multi-tenant management and resource isolation is enabled, DRS can migrate data of all tenants. However, DRS does not synchronize tenant metadata, so tenant information cannot be synchronized to the destination instance. To migrate a tenant from an instance to another instance, perform the following steps:

  1. Select an instance that supports multi-tenant management 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.
• 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.

• 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 the Multi-Tenant Mode

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;

• 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;

• 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.
• 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@host2; 

  Rename a user under a common tenant.

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

  Dropping a user

  Drop a user from a system tenant.

  DROP USER [IF EXISTS] user_name@host; 

  Drop a user from 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@host2;

  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';

• 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 under 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 from a system tenant.

  DROP DATABASE [IF EXISTS] `db_name`;

  Drop a database from a common tenant.

  DROP DATABASE [IF EXISTS] `db_name@tanant_name`;

• Managing databases under a common tenant

  Create a database for the current tenant.

  CREATE DATABASE [IF NOT EXISTS] 'db_name'; 

  Drop a database from the current tenant.

  DROP DATABASE [IF EXISTS] 'db_name';

• 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;

  

  • 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 pwssword;
  mysql --host=**** -u user1@tenant_1 -D db1@tenant_1 -p pwssword;

  After the connection is successful, the user is restricted by the resources of the corresponding 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.

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));

  

  • 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));

  

  • 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));

  

  • 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));

  

  • 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));

  

  • 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));

  

  • 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));

  

  • 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));

  

  • 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));

  

  • 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

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;

  

  • 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;

  

  • 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.