Overview of Multi-Tenant Management

• Tenant: Tenants are under a DB instance and above databases and users. Tenants are used for data isolation and resource isolation. However, actual database access must still be authenticated as a specific user.
  • There are system tenants and regular tenants based on data isolation.
    • System tenant (sys_tenant): System tenants are designed to accommodate users who 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.
    • Regular tenant (user_tenant): You can create regular tenants as a system tenant. The users and databases of each regular tenant are completely isolated from those of other regular tenants. In addition, regular tenants cannot access databases of the system tenants.
  • There are dedicated tenants and shared tenants based on resource isolation. The resources available to tenants, currently limited to vCPUs, are determined by tenant-level resource configurations.
    • 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.
• Tenant-level 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.

Figure 2 Tenant-level data isolation and resource configuration

As shown in the figure, when a user logs in to the instance as the system tenant and creates DB1, DB3, and USER1, the names of these databases and the username remain unchanged. The system tenant can view all databases and users under regular tenants, but the names of the databases and users displayed to the system tenant change. For example, DB1, USER1, and USER2 of tenant1 will be displayed as DB1@tenant1, USER1@tenant1, and USER2@tenant1. DB1, DB2, and USER1 of tenant2 will be displayed as DB1@tenant2, DB2@tenant2, and USER1@tenant2.

TaurusDB uses different tenant name suffixes to distinguish databases and users of different tenants. When a user logs in to the instance as tenant1, the databases and users are displayed as DB1, DB2, USER1, and USER2. The same rule applies to tenant2. If DB2 exists before multi-tenancy is enabled, DB2 will belong to the system tenant by default after multi-tenancy is enabled. You can also assign DB2 to other tenants using the syntax provided by TaurusDB. For details, see the following sections.

When it comes to resource isolation, a system tenant can use default resource configurations or customize ones. In the preceding figure, the system tenant can use a minimum of 1 vCPU and a maximum of 2 vCPUs. tenant1 can use a minimum of 0 vCPUs (which indicates that it is a shared tenant) and a maximum of 4 vCPUs. tenant2 can use a minimum of 3 vCPUs (which indicates that it is a dedicated tenant) and a maximum of 4 vCPUs.

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.

• 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 directives. Only one resource plan can be enabled per tenant.

  Figure 3 User-level resource configuration relationship
  

  The figure above shows an instance with 4 vCPUs and a dedicated tenant (Tenant_1). The tenant can use a minimum of 1 vCPU and a maximum of 4 vCPUs. All users under the tenant share the tenant resources. There are two resource plans (plan1 and plan2). plan1 has one plan directive (plan_directive1), and plan2 has two plan directives (plan_directive2 and plan_directive3).

  • plan_directive2: states that consumer_group1 can use a minimum of 60% and a maximum of 100% of Tenant_1's vCPUs.
  • plan_directive3: states that consumer_group2 can use a minimum of 40% and a maximum of 100% of Tenant_1's vCPUs.

  When plan2 is enabled, the user-level vCPU limits specified by plan_directive2 and plan_directive3 take effect. user_1 belongs to consumer_group1, so its vCPU limits are determined by plan_directive2. The same rule applies to user_2 and user_3.