Help Center/ TaurusDB/ Kernel/ Multi-tenancy/ Examples of Using Multi-Tenancy for Resource Isolation
Updated on 2026-08-04 GMT+08:00
View PDF
Share

Examples of Using Multi-Tenancy for Resource Isolation

Scenarios

This section provides examples of using multi-tenancy to isolate resources. Follow the procedures below to test and understand how to use this feature.

Test Environment

  • The ECS and the TaurusDB cluster are in the same region and AZ.
  • The TaurusDB cluster nodes are configured with 8 vCPUs and 32 GB of memory, with a total of two nodes (one primary node and one read replica).
  • The default parameter template is used and multi-tenancy is enabled.
  • The ECS is configured with 32 vCPUs. Its specifications must be higher than the cluster specifications to prevent ECS performance bottlenecks during stress testing, which could affect multi-tenant resource isolation.

Creating Resource Configurations

Log in to the DB instance using the privileged root account and create multiple resource configurations to restrict tenant resources.

create resource_config cfg_1 MAX_CPU 4 MIN_CPU 1;
create resource_config cfg_2 MAX_CPU 2 MIN_CPU 1;

After creating the resource configurations, you can view all resource configurations by querying the __taurus_sys__.tenant_resource_configs table:

SELECT * FROM __taurus_sys__.tenant_resource_configs;

Creating Tenants

Log in to the DB instance using a privileged account. Create two tenants, tenant_1 and tenant_2 and bind each to a specific resource configuration.

create tenant tenant_1 RESOURCE_CONFIG cfg_1;
create tenant tenant_2 RESOURCE_CONFIG cfg_2;
  • When creating tenant_1, associate it with resource configuration cfg_1. The vCPU resource limit min_cpu for this tenant is set to 1, meaning that a minimum quota of 1 vCPU is guaranteed during background resource scheduling. The maximum vCPU quota for this tenant is capped at 4 vCPUs.
  • When creating tenant_2, associate it with resource configuration cfg_2. The vCPU resource limit min_cpu for this tenant is set to 1, meaning that a minimum quota of 1 vCPU is guaranteed during background resource scheduling. The maximum vCPU quota for this tenant is capped at 2 vCPUs.

After the tenants are created, you can view all tenants by querying the __taurus_sys__.tenant table:

SELECT * FROM __taurus_sys__.tenant;

Creating Users and Databases

After the tenants are created, create users and databases under each tenant.

  1. Create user user_1 under tenant_1 and grant user_1 all execution privileges within tenant_1. Here, user_1@tenant_1 can be treated as a privileged account within tenant_1.
    1. Create user_1@tenant_1 under the system tenant. 
      CREATE user 'user_1@tenant_1' IDENTIFIED WITH mysql_native_password BY {password};
    2. Grant user_1@tenant_1 all execution privileges of tenant_1 using a privileged account. 
      GRANT all privileges ON `%@tenant_1`.* to 'user_1@tenant_1'@'%' with grant option;
  2. Create user user_2 under tenant_1 and grant user_2 all execution privileges within tenant_1. Here, user_2@tenant_1 can be treated as a privileged account within tenant_1.
    1. Create user_2@tenant_1 under the system tenant. 
      CREATE user 'user_2@tenant_1' IDENTIFIED WITH mysql_native_password BY {password};
    2. Grant user_2@tenant_1 all execution privileges of tenant_1 using a privileged account. 
      GRANT all privileges ON `%@tenant_1`.* to 'user_2@tenant_1'@'%' with grant option;
  3. To connect to the DB instance using the user account, run the following SQL statement: 
    mysql --host=xxxxxx -u user_1@tenant_1 -p password

    After the login succeeds, you can only view databases under this tenant. Databases belonging to the system tenant or other tenants remain invisible to this account.

After creating users and databases under tenant_1, you can follow the same method to create users and databases under tenant_2.

Testing

After resource configurations, tenants, users, and databases are created, verify multi-tenant resource isolation in the following scenarios.

Scenario 1: Testing Tenant-level vCPU Resource Isolation

  1. Run Sysbench stress tests and check vCPU utilization.

    Run the following stress testing commands. The parameters below are for demonstration purposes and can be adjusted as needed.

    sysbench --db-driver=mysql --mysql-host=host --mysql-port=port --mysql-user=user_1@tenant_1 --mysql-password=password --mysql-db=sbtest --table_size=250000 --tables=25 --time=180 --threads=thread_num --percentile=95 --report-interval=1 oltp_read_write run
    sysbench --db-driver=mysql --mysql-host=host --mysql-port=port --mysql-user=user_1@tenant_2 --mysql-password=password --mysql-db=sbtest --table_size=250000 --tables=25 --time=180 --threads=thread_num --percentile=95 --report-interval=1 oltp_read_write run

    Run Sysbench tests for both tenant_1 and tenant_2 and compare their vCPU utilization and TPS/QPS metrics.

    Figure 1 Sysbench stress test results
  2. Analyze the results.

    The period 10:58-11:00 corresponds to the test results of tenant_1 and 11:01-11:03 corresponds to the test results of tenant_2.

    The vCPU usage ratio of tenant_1 to tenant_2 is close to 2:1. Similarly, the TPS/QPS ratio of tenant_1 to tenant_2 is also close to 2:1.

    tenant_1 can use up to 4 vCPUs in the system and tenant_2 can use up to 2 vCPUs.

Scenario 2: Testing User-level vCPU Resource Isolation

  1. Create users.

    Use tenant_1 created earlier and its users user_1 and user_2.

  2. Create resource consumer groups.

    Connect to the DB instance as tenant_1, create resource consumer groups group1 and group2, and associate group1 with user_1 and group2 with user_2.

    mysql --host=xxxxxx -u user1@tenant_1 -p password
    CALL dbms_resource_manager.create_consumer_group('group1', 'comment');
CALL dbms_resource_manager.create_consumer_group('group2', 'comment');
CALL dbms_resource_manager.set_consumer_group_mapping('USER', 'user_1', 'group1');
CALL dbms_resource_manager.set_consumer_group_mapping('USER', 'user_2', 'group2');

    After the resource consumer groups are created, you can view all resource configurations by querying the __taurus_sys__.consumer_groups and __taurus_sys__.group_mapping_rules tables:

    SELECT * FROM __taurus_sys__.consumer_groups;
SELECT * FROM __taurus_sys__.group_mapping_rules;
  3. Create a resource plan and directives.
    1. Connect to the DB instance as tenant_1.
    2. Create resource plan plan1 and configure resource plan directive plan_directive_for_user1. This directive associates plan1 with group1 and sets mgmt_p1 to 10 and utilization_limit to 40. 
      CALL dbms_resource_manager.create_plan('plan1', 'comment')
CALL dbms_resource_manager.create_plan_directive('plan1', 'group1', 'plan_directive_for_user1', 10, 40);
    3. Under resource plan plan1, create directive plan_directive_for_user2 to associate plan1 with group2 and set mgmt_p1 to 10 and utilization_limit to 40. 
      CALL dbms_resource_manager.create_plan_directive('plan1', 'group2', 'plan_directive_for_user2', 10, 40);
    4. After the resource plan is created, you can view all configured resources by querying the __taurus_sys__.resource_plans and __taurus_sys__.plan_directives tables. 
      SELECT * FROM __taurus_sys__.resource_plans;
SELECT * FROM __taurus_sys__.plan_directives;
  4. Enable the resource plan.

    Connect to the DB instance as tenant_1.

    CALL dbms_resource_manager.set_resource_manager_plan('plan1');
  5. Run Sysbench stress tests and check vCPU utilization. 
    sysbench --db-driver=mysql --mysql-host=host --mysql-port=port --mysql-user=user_1@tenant_1 --mysql-password=password --mysql-db=sbtest --table_size=250000 --tables=25 --time=180 --threads=thread_num --percentile=95 --report-interval=1 oltp_read_write run
    sysbench --db-driver=mysql --mysql-host=host --mysql-port=port --mysql-user=user_2@tenant_1 --mysql-password=password --mysql-db=sbtest --table_size=250000 --tables=25 --time=180 --threads=thread_num --percentile=95 --report-interval=1 oltp_read_write run

    Run Sysbench tests for both user_1 and user_2 under tenant_1 and compare their vCPU utilization and TPS/QPS metrics.

    Figure 2 Sysbench stress test results

    Connect to the DB instance as tenant_1 to view tenant-level and user-level vCPU utilization in real time:

    select * from information_schema.CPU_SUMMARY_BY_TENANT order by tenant_name;
    select * from information_schema.CPU_SUMMARY_BY_USER order by tenant_name, user_name;
  6. Analyze the results.

    The period 11:15–11:17 corresponds to the test results for user_1@tenant_1 and 11:19–11:21 corresponds to the test results for user_2@tenant_1.

    The vCPU usage ratio of user_1@tenant_1 to user_2@tenant_1 is close to 1:1. Similarly, the TPS/QPS ratio of user_1@tenant_1 to user_2@tenant_1 is also close to 1:1.

    user_1@tenant_1 can use up to 40% of the vCPUs allocated to tenant_1, and the same applies to user_2@tenant_1.

Parent Topic: Multi-tenancy