租户扩缩容资源规划

在对租户进行扩缩容操作前，可以根据租户当前的资源使用情况以及扩缩容计划，进行资源规划。

背景信息

在当前版本中，OceanBase 数据库支持租户的同构 Zone 模式和异构 Zone 模式：

• 同构 Zone 模式下，要求租户下各 Zone 的 UNIT_NUM 必须相同。
• 异构 Zone 模式下，租户下各 Zone 的 UNIT_NUM 可以相同也可以不同，但一个租户的所有 Zone 最多只能有两种 UNIT_NUM。

本文以同构 Zone 模式下租户的扩缩容资源规划为例，提供操作指导。异构 Zone 模式下租户的操作类似。

调大 Unit number 或增加 Primary Zone 等租户扩容场景

对于调大 Unit number 或增加 Primary Zone 等租户扩容场景，在扩容时，可能会通过新建日志流来实现数据均衡，而新建日志流需要更多的资源，故在扩容前需要提前确认 Unit 资源是否符合要求。

1. 使用 root 用户登录到集群的 sys 租户。

   obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -A
   

2. 进入 oceanbase 数据库。

   obclient(root@sys)[(none)]> USE oceanbase;
   

3. 查看租户在每个 Unit 上逻辑资源的使用情况。

   obclient(root@sys)[Oceanbase]> SELECT * FROM oceanbase.GV$OB_TENANT_RESOURCE_LIMIT WHERE TENANT_ID=1002;
   

   查询结果如下：

   +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+
   | SVR_IP         | SVR_PORT | TENANT_ID | ZONE  | RESOURCE_NAME | CURRENT_UTILIZATION | MAX_UTILIZATION | RESERVED_VALUE | LIMIT_VALUE | EFFECTIVE_LIMIT_TYPE |
   +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+
   | 172.xx.xxx.xxx |     2882 |      1002 | zone1 | ls            |                   2 |               2 |              0 |          13 | memory               |
   | 172.xx.xxx.xxx |     2882 |      1002 | zone1 | tablet        |                 668 |             668 |              0 |      100000 | configuration        |
   +----------------+----------+-----------+-------+---------------+---------------------+-----------------+----------------+-------------+----------------------+
   2 rows in set
   

   从第一行结果可知，用户租户 1002 在 172.xx.xxx.xxx:2882 节点上，当前有 2 个日志流（CURRENT_UTILIZATION），曾经同时存在过最多 2 个日志流（MAX_UTILIZATION），最大可以创建 13 个日志流（LIMIT_VALUE），并且这 13 个日志流的上限值由租户内存（memory）计算得来。

   从第二行结果可知，用户租户 1002 在 172.xx.xxx.xxx:2882 节点上，当前有 668 个 TABLET（CURRENT_UTILIZATION），曾经同时存在过最多 668 个 TABLET（MAX_UTILIZATION），最大可以创建 100000 个 TABLET（LIMIT_VALUE），并且这 100000 个 TABLET 的上限值是根据配置项值（configuration）计算得来。

4. 根据实际扩容场景，计算扩容后所需的逻辑资源。

   在 OceanBase 数据库中，租户 LS 和 Tablet 相关的计算公式如下：

   • 用户租户所有节点上达到稳定状态的日志流个数

     • 当前用户租户有广播日志流时：U * P + 2

     • 当前用户租户没有广播日志流时：U * P + 1

   • 由于任何一个日志流都可能将分区 Transfer 到其他日志流上，同一个节点内的日志流之间 Transfer 时不会新建日志流，不同节点的日志流之间 Transfer 时会新建一个日志流。发生 Transfer 时，用户租户最大的临时日志流个数：(U * P) * ((U - 1) * P)

   • 发生 Transfer 时，单个节点上的最大日志流个数：((U * P) * ((U - 1) * P)) / U + (P + 2)

   • 用户租户在每个节点上能够创建 Tablet 个数的上限

     • 受配置项值限制的上限：(MEMORY_SIZE/1GB) * _max_tablet_cnt_per_gb

     • 受租户内存限制的上限：(MEMORY_SIZE * _storage_meta_memory_limit_percentage) / 200MB * 20000

   上述公式中，U 在同构 Zone 模式下，表示租户的 UNIT_NUM 数值，异构 Zone 模式下表示租户两个不同 UNIT_NUM 的最小公倍数；P 表示租户 PRIMARY_ZONE 的第一优先级个数。有关上述公式中其他参数的详细说明，请参见 查看租户和资源信息。

   根据上述计算公式，假设一同构 Zone 模式的租户 1002 PRIMARY_ZONE 第一优先级的个数为 1， UNIT_NUM 数为 2，有广播日志流。现在需要将租户的 PRIMARY_ZONE 第一优先级个数修改为 3，则该租户所有节点上达到稳定状态的日志流个数即为 8（2*3 + 2）个。如果这些日志流发生 Transfer，则单个节点上同时存在的最大日志流个数 MAX_UNTILIZATION 可能需要达到 14（((2 * 3) *（2-1）*3)/2 + 3 + 2）个，故需要对租户进行扩容，以便能够承载 14 个日志流。

5. 计算出扩容后所需的逻辑资源后，结合节点当前逻辑资源受限的因素，确认需要调整的物理资源或配置项。

   由于租户在每个节点上能创建的逻辑资源会受到各种物理资源或配置项值的限制，可以通过视图 GV$OB_TENANT_RESOURCE_LIMIT_DETAIL 来查看租户逻辑资源具体所受的限制及各种限制的上限值。

   obclient(root@sys)[Oceanbase]> SELECT * FROM oceanbase.GV$OB_TENANT_RESOURCE_LIMIT_DETAIL WHERE TENANT_ID=1002;
   

   查询结果如下：

   +----------------+----------+-----------+---------------+---------------+---------------------+
   | SVR_IP         | SVR_PORT | TENANT_ID | RESOURCE_NAME | LIMIT_TYPE    | LIMIT_VALUE         |
   +----------------+----------+-----------+---------------+---------------+---------------------+
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | configuration |                  90 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | memstore      | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | memory        |                  13 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | data_disk     | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | clog_disk     |                  32 |
   | 172.xx.xxx.xxx |     2882 |      1002 | ls            | cpu           | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | configuration |              100000 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | memstore      | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | memory        |              102400 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | data_disk     | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | clog_disk     | 9223372036854775807 |
   | 172.xx.xxx.xxx |     2882 |      1002 | tablet        | cpu           | 9223372036854775807 |
   +----------------+----------+-----------+---------------+---------------+---------------------+
   12 rows in set
   

   从查询结果可知，租户 1002 在 172.xx.xxx.xxx:2882 节点上，限制创建的日志流个数的因素为：配置项（configuration）为 90、租户内存（memory）为 13、日志盘（clog_disk）为 32。限制创建 Tablet 个数的因素为：配置项（configuration）为 100000、租户内存（memory）为 102400。

   根据这些上限值，可以确认需要调整的物理资源。例如，上面的示例中，如果希望单个节点最大可承载 14 个日志流，则需要调整租户内存（memory）和日志盘（CLOG_DISK）。

6. 根据扩容后所需的逻辑资源，计算扩容后单个节点所需的物理资源量。

   假设扩容后，单个节点所需的最大临时日志流个数为 14，最多需要创建的 Tablet 个数为 40000 的示例如下：

   obclient(root@sys)[Oceanbase]> CALL DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES("LS:14, TABLET:40000");
   

   计算结果如下：

   +------------------------+------------+
   | PHYSICAL_RESOURCE_NAME | MIN_VALUE  |
   +------------------------+------------+
   | memstore               |          0 |
   | memory                 | 5553258496 |
   | data_disk              |          0 |
   | clog_disk              | 7516192768 |
   | cpu                    |          0 |
   +------------------------+------------+
   5 rows in set
   

7. 根据得到的结果，参考 通过调整资源规格实现租户扩缩容，调大租户资源规格。

租户缩容场景

对于租户缩容场景，也可以参考上述扩容场景中的方法，估算出业务运行所需的逻辑资源需求量后，再调用 DBMS_OB_LIMIT_CALCULATOR 系统包中的 CALCULATE_MIN_PHY_RES_NEEDED_BY_LOGIC_RES 子程序，计算出这些逻辑资源所需的物理资源量，最后根据业务实际情况，适当调小租户的资源规格。

此外，对于同构 Zone 模式的租户，通过调整 Unit Number 实现租户缩容时，如果租户有多个 Unit Group（在视图 DBA_OB_UNITS 中，不同 Zone 之间相同 UNIT_GROUP_ID 的 Unit 属于同一个 Unit Group），且每个 Unit Group 均比较空闲，不确定选择哪一个 Unit Group 进行删除时，可以通过以下方法来完成。

同样，对于异构 Zone 模式的租户，通过调整租户单个资源池的 Unit Number 来实现租户缩容时，如果每个 Unit 均比较空闲，不确定选择哪一个 UNIT_LIST 进行删除时，也可以通过以下方法来完成。

1. 使用 root 用户登录到集群的 sys 租户。

   obclient -h172.30.xxx.xxx -P2883 -uroot@sys#obdemo -pxxxx -A
   

2. 进入 oceanbase 数据库。

   obclient(root@sys)[(none)]> USE oceanbase;
   

3. 查看待缩容的租户所拥有的 Unit。

   obclient(root@sys)[Oceanbase]> SELECT UNIT_ID, TENANT_ID, STATUS, RESOURCE_POOL_ID, UNIT_GROUP_ID, ZONE, SVR_IP, SVR_PORT FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID = 1002; 
   

   查询结果如下：

   +---------+-----------+--------+------------------+---------------+-------+----------------+----------+
   | UNIT_ID | TENANT_ID | STATUS | RESOURCE_POOL_ID | UNIT_GROUP_ID | ZONE  | SVR_IP         | SVR_PORT |
   +---------+-----------+--------+------------------+---------------+-------+----------------+----------+
   |    1016 |      1002 | ACTIVE |             1003 |          1006 | zone1 | xxx.xx.xxx.194 |     2882 |
   |    1017 |      1002 | ACTIVE |             1003 |          1007 | zone1 | xxx.xx.xxx.198 |     2882 |
   |    1018 |      1002 | ACTIVE |             1003 |          1006 | zone2 | xxx.xx.xxx.192 |     2882 |
   |    1019 |      1002 | ACTIVE |             1003 |          1007 | zone2 | xxx.xx.xxx.196 |     2882 |
   |    1020 |      1002 | ACTIVE |             1003 |          1006 | zone3 | xxx.xx.xxx.204 |     2882 |
   |    1021 |      1002 | ACTIVE |             1003 |          1007 | zone3 | xxx.xx.xxx.197 |     2882 |
   +---------+-----------+--------+------------------+---------------+-------+----------------+----------+
   6 rows in set
   

   根据查询结果，待缩容的租户的每个 Zone 均有 2 个 Unit。UNIT_ID 分别为 1016、1017、1018、1019、1020、1021。

4. 执行以下命令，分别计算租户内各 Unit 所需的最小物理资源。

   需要分别获取各 Unit 所需的最小物理资源。例如，本示例中，UNIT_ID 为 1018 的 Unit 对应的节点为xxx.xx.xx.192:2882。

   获取用户租户 1002 在 xxx.xx.xx.192:2882 节点上的 Unit 所需的最小物理资源的示例如下：

   obclient(root@sys)[Oceanbase]> CALL DBMS_OB_LIMIT_CALCULATOR.CALCULATE_MIN_PHY_RES_NEEDED_BY_UNIT(TENANT_ID => 1002, SERVER => "xxx.xx.xx.192:2882");
   

   执行结果如下：

   +----------------+----------+-----------+------------------------+------------+
   | SVR_IP         | SVR_PORT | TENANT_ID | PHYSICAL_RESOURCE_NAME | MIN_VALUE  |
   +----------------+----------+-----------+------------------------+------------+
   | xxx.xx.xxx.192 |     2882 |      1002 | memstore               |          0 |
   | xxx.xx.xxx.192 |     2882 |      1002 | memory                 | 4294967296 |
   | xxx.xx.xxx.192 |     2882 |      1002 | data_disk              |          0 |
   | xxx.xx.xxx.192 |     2882 |      1002 | clog_disk              | 1073741824 |
   | xxx.xx.xxx.192 |     2882 |      1002 | cpu                    |          0 |
   +----------------+----------+-----------+------------------------+------------+
   5 rows in set
   

   参考以上方法，依次获取所有 Unit 所需的最小物理资源后，对于同构 Zone 模式的租户，选择资源需求量相对较少的 Unit Group 进行删除；对于异构 Zone 模式的租户，选择资源池中资源需求量相对较少的 UNIT_LIST 进行删除即可。

相关文档

• 查看租户和资源信息

• 通过调整资源规格实现租户扩缩容

• 通过调整 Unit Number 实现租户扩缩容

• 通过调整 Primary Zone 实现租户扩缩容