Tenant-level scaling

Tenant scaling essentially involves increasing or decreasing a tenant's service capabilities, including computing power and storage capacity. The following sections describe the tenant scaling features provided by OceanBase Database, focusing on horizontal and vertical scaling.

Horizontal scaling

In OceanBase Database, a tenant's storage capacity and read/write service capabilities are influenced by factors such as the number of unit numbers, the number of first-priority zones, and locality.

Adjusting the number of unit numbers

A unit number, also known as the UNIT_NUM of a resource pool, represents the number of units that provide services for a tenant in each zone. By adjusting the UNIT_NUM of a tenant's resource pool, you can increase or decrease the number of nodes serving the tenant in a zone, thereby changing the tenant's overall service capability and achieving scaling.

Adjusting the UNIT_NUM of a resource pool includes increasing and decreasing it. When adjusting the UNIT_NUM, note the following:

• For tenants in homogeneous zone mode:

  • If there are multiple resource pools and they are not allocated to the tenant, you can individually increase or decrease the UNIT_NUM of a specific resource pool.

  • If all resource pools are allocated to the tenant, you can only adjust the UNIT_NUM of all resource pools simultaneously; individual adjustment is not possible.

• For tenants in heterogeneous zone mode, if there are multiple resource pools, you can adjust them regardless of whether they are allocated to the tenant. That is, you can either adjust the UNIT_NUM of all resource pools simultaneously or individually increase or decrease the UNIT_NUM of a specific resource pool.

Increasing or decreasing the UNIT_NUM essentially involves adding or deleting units. For detailed operations on increasing or decreasing the UNIT_NUM, see Implement tenant scaling by adjusting the number of unit numbers.

Adjusting the number of first-priority zones

A primary zone is a list of zones that provide read/write services. By increasing or decreasing the number of first-priority zones, you can add or remove zones providing read/write services, thereby achieving horizontal scaling of read/write services across zones.

Adjusting the number of first-priority zones includes two scenarios: increasing and decreasing the number of first-priority zones.

For detailed operations on adjusting the number of first-priority zones, see Implement tenant scaling by adjusting primary zones.

Modifying locality

Locality refers to the distribution strategy of data replicas across zones. By modifying locality, you can increase or decrease the number of replicas for each piece of data of a tenant, thereby changing the service scope of the tenant's data across zones.

Modifying locality includes two methods: increasing the number of replicas and decreasing the number of replicas.

• Increase the number of replicas

  Increasing the number of replicas is mainly used in the following scenarios:

  • Scenario 1: Upgrade the number of tenant replicas to improve tenant availability.

    For example, upgrade a tenant from 3 replicas (F@z1,F@z2,F@z3) to 5 replicas (F@z1,F@z2,F@z3,F@z4,F@z5), expanding the data range from 'z1', 'z2', 'z3' to 'z1','z2','z3','z4','z5' to improve tenant availability.

  • Scenario 2: When migrating data from one IDC (zone) to another, complete the data in the new IDC.

    Data completion in the new IDC is a sub-operation of data migration within an IDC. Suppose a tenant wants to migrate data from IDC z1 to z4. First, data needs to be added in z4 by modifying locality. During the data replica migration between IDCs, data is completed in the new IDC.

• Reduce the number of replicas

  Reducing the number of replicas is mainly used in the following scenarios:

  • Scenario 1: Downgrade the number of replicas for a tenant to reduce its storage resource usage.

    For example, downgrade a tenant from 5 replicas (F@z1,F@z2,F@z3,F@z4,F@z5) to 3 replicas (F@z1,F@z2,F@z3), reducing the data range from 'z1','z2','z3','z4','z5' to 'z1','z2','z3', thereby reducing the tenant's storage resource usage.

  • Scenario 2: Delete data in the old IDC when migrating data from one IDC (Zone) to another.

    Deleting data in the old IDC is another sub-operation of data migration within an IDC. Suppose a tenant wants to migrate data from IDC z1 to z4. After adding data in z4, data needs to be deleted in IDC z1 by modifying locality, ultimately achieving the migration of tenant data from z1 to z4.

For detailed operations on modifying locality, see Modify locality.

Vertical scaling

Vertical scaling refers to adjusting the unit config of a tenant's resource pool to change the service capability of the tenant across nodes, thereby altering the overall service capability and enabling scale-up or scale-down.

There are mainly two ways to adjust the unit config of a tenant's resource pool:

• Switch to a new unit config (unit_config)

  Switching to a new unit config involves adjusting the unit config of each resource unit in the resource pool, thereby adjusting the tenant's unit config and service capability in that resource pool.

• Modify the current unit config (unit_config)

  Modifying the current unit config involves directly adjusting values such as CPU or memory of the current unit config, thereby directly affecting the tenant's unit config and service capability in that resource pool.

Typically, both switching to a new unit config and modifying the current unit config can adjust the tenant's service capability. At the tenant level, this essentially adjusts the unit config of the tenant's resource pool. Modifications to the unit config mainly include two scenarios: increasing the unit config and decreasing the unit config.

• Increase the unit config

  When increasing the unit config, whether by switching to a new unit config or modifying the current unit config, the total adjusted resources must meet the following requirement:

  Sum(min_cpu) <= CPU_CAPACITY
  
  Sum(memory_size) <= MEM_CAPACITY
  
  Sum(max_cpu) <= CPU_CAPACITY * resource_hard_limit
  

  Where:

  • CPU_CAPACITY: The total CPU capacity per node.

  • MEM_CAPACITY: The total memory capacity per node.

  • resource_hard_limit: Defines the CPU resource overprovisioning percentage. A value greater than 100 indicates overprovisioning is allowed.

• Decrease the unit config

  When decreasing the unit config, note that the MEMORY_SIZE in the unit config cannot be lower than the actual memory size already used by the tenant on the current node (MEM_USED). If MEMORY_SIZE < MEM_USED, the unit config adjustment will fail.

For detailed operations on upgrading and downgrading resource specifications, see Scale tenants by adjusting their resource specifications.