体验水平扩展与弹性伸缩

弹性伸缩是 OceanBase 从小规模体验环境演进到更大业务容量的关键能力。随着业务的发展或衰退，以及业务在不同时段的峰值差异，数据库需要提供弹性的服务能力。OceanBase 数据库通过租户扩缩容功能支持业务的弹性服务能力：扩容可以提升计算能力和存储容量，既可以通过提高单节点的服务能力达成，也可以通过增加服务节点达成；缩容是扩容的反操作。所有调整均在线生效，对业务透明。

本文将引导您完成以下体验：

• 理解扩缩容体系：掌握租户垂直扩缩容（调整资源规格）、租户水平扩缩容（调整 Unit Number）与集群扩容（新增节点）三个层面的扩展能力。
• 体验租户垂直扩容：在线调大租户的资源规格，观察资源变化的即时生效。
• 对比扩容前后的业务容量：对同一租户在扩容前后执行相同参数的压测，观察 QPS 与延迟的变化。
• 掌握扩缩容验证方法：通过系统视图确认资源规格、Unit 分布与任务执行状态。

前提条件

在开始本文操作前，确保满足以下条件：

扩缩容体系简介

租户扩容或缩容本质上是提高或降低租户的服务能力，包括计算能力和存储容量。OceanBase 数据库提供了两种途径来实现租户的扩缩容，加上集群层面的节点扩展，共同构成完整的弹性伸缩体系：

其中，租户垂直扩缩容又包括两种方法：

• 修改资源配置：直接调整资源配置的 CPU 或 Memory 等值，影响所有使用该规格的资源单元。
• 切换资源配置：为资源池切换到另一套资源配置（ALTER RESOURCE POOL pool1 UNIT='uc2';），适用于多个租户共用同一资源规格、只希望调整其中一个租户的场景。

体验租户垂直扩容

本节创建一个小规格租户 scale_tenant（1C2G），执行一轮点查压测作为基线，然后在线将其规格扩容为 2C4G，再次执行相同参数的压测，对比扩容前后业务容量的变化。

操作步骤

1. 使用 root 用户登录集群的 sys 租户（密码为部署时随机生成的密码，获取方式见上文前提条件），创建体验租户：

   obclient [oceanbase]> CREATE RESOURCE UNIT scale_unit MAX_CPU=1, MIN_CPU=1, MEMORY_SIZE='2G';
   obclient [oceanbase]> CREATE RESOURCE POOL scale_pool UNIT='scale_unit', UNIT_NUM=1, ZONE_LIST=('zone1');
   obclient [oceanbase]> CREATE TENANT IF NOT EXISTS scale_tenant CHARSET='utf8mb4', PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('scale_pool') SET ob_tcp_invited_nodes='%';
   

   CREATE TENANT 为同步操作，命令执行约 10 秒后返回，期间请耐心等待。

2. 执行扩容前的基线压测。使用点查脚本对 scale_tenant 发起压测，记录结果中的 QPS 和 95% 延迟：

   obd test sysbench demo --tenant=scale_tenant --script-name=oltp_point_select.lua --table-size=100000 --threads=16 --rand-type=uniform
   

   点查是典型的 CPU 密集型负载。如果集群 CPU 资源紧张，1C 的 CPU 配额将成为吞吐瓶颈；如果集群 CPU 资源富余，租户实际可使用的 CPU 可能超过其配额，两轮压测的 QPS 差异可能不明显（详见下文结果解读）。

3. 查看当前资源规格，确认扩容前的基线：

   obclient [oceanbase]> SELECT UNIT_CONFIG_ID, NAME, MAX_CPU, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE
                       FROM oceanbase.DBA_OB_UNIT_CONFIGS WHERE NAME='scale_unit';
   

   返回结果示例如下（UNIT_CONFIG_ID 由系统分配，因环境而异）：

   +----------------+------------+---------+---------+-------------+---------------+
   | UNIT_CONFIG_ID | NAME       | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE |
   +----------------+------------+---------+---------+-------------+---------------+
   |           1009 | scale_unit |       1 |       1 |  2147483648 |    6442450944 |
   +----------------+------------+---------+---------+-------------+---------------+
   1 row in set
   

   查询结果显示，scale_unit 资源单元的 CPU、内存分别为 1C、2G，日志盘空间为 6G（默认等于 3 倍内存大小）。

4. 在线将租户规格扩容为 2C4G：

   obclient [oceanbase]> ALTER RESOURCE UNIT scale_unit MAX_CPU=2, MIN_CPU=2, MEMORY_SIZE='4G';
   Query OK, 0 rows affected
   

   语句秒级返回即表示扩容完成，租户的 CPU 和内存资源立即生效，无需数据迁移或切换，压测或业务运行中的会话不受影响（本文实测在压测进行中执行本语句与后文缩容语句，压测均正常完成、零错误）。ALTER 语句仅调整显式指定的选项，LOG_DISK_SIZE 保持不变，如需同时调整日志盘规格，可在语句中一并指定。

5. 确认资源规格已变更：

   obclient [oceanbase]> SELECT UNIT_CONFIG_ID, NAME, MAX_CPU, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE
                       FROM oceanbase.DBA_OB_UNIT_CONFIGS WHERE NAME='scale_unit';
   

   返回结果中 MAX_CPU 和 MIN_CPU 已变为 2，MEMORY_SIZE 已变为 4294967296（即 4G）：

   +----------------+------------+---------+---------+-------------+---------------+
   | UNIT_CONFIG_ID | NAME       | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE |
   +----------------+------------+---------+---------+-------------+---------------+
   |           1009 | scale_unit |       2 |       2 |  4294967296 |    6442450944 |
   +----------------+------------+---------+---------+-------------+---------------+
   1 row in set
   

   还可以通过 GV$OB_UNITS 视图查看资源单元在节点上的实际生效值：

   obclient [oceanbase]> SELECT TENANT_ID, SVR_IP, ZONE, MAX_CPU, MIN_CPU, MEMORY_SIZE/1024/1024/1024 AS MEMORY_SIZE_G
                       FROM oceanbase.GV$OB_UNITS
                       WHERE TENANT_ID=(SELECT TENANT_ID FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME='scale_tenant');
   

   +-----------+--------------+-------+---------+---------+----------------+
   | TENANT_ID | SVR_IP       | ZONE  | MAX_CPU | MIN_CPU | MEMORY_SIZE_G  |
   +-----------+--------------+-------+---------+---------+----------------+
   |      1020 | 127.0.0.1    | zone1 |       2 |       2 | 3.000000000000 |
   +-----------+--------------+-------+---------+---------+----------------+
   1 row in set
   

6. 再次执行相同参数的压测，与基线结果对比：

   obd test sysbench demo --tenant=scale_tenant --script-name=oltp_point_select.lua --table-size=100000 --threads=16 --rand-type=uniform
   

7. 对比两轮测试结果，重点确认：

   • 两轮压测均正常结束且无错误：说明扩容后租户可正常承载业务流量，规格调整对业务无感知；
   • QPS 差异可能不明显：MAX_CPU 是资源上限而非保证值。集群 CPU 资源富余时，租户实际可使用的 CPU 可能超过其配额，扩容前后测出的 QPS 相近属正常现象；规格提升的收益主要体现在集群资源紧张、租户间存在 CPU 争抢时；
   • 95% 延迟同量级小幅波动：CPU 富余时请求排队时间本就很短，扩容前后均在亚毫秒级。

结果解读

体验租户缩容

缩容是扩容的反操作，可将资源规格调回原值以释放资源：

obclient [oceanbase]> ALTER RESOURCE UNIT scale_unit MAX_CPU=1, MIN_CPU=1, MEMORY_SIZE='2G';

语句同样秒级返回。本文实测在压测进行中将规格从 2C4G 调回 1C2G，变更瞬间完成，压测全程零错误、零重连，业务无感知。

调小资源规格时需注意对 MEMORY_SIZE 的限制：为租户提供服务的每台物理机，需要满足资源配置的 MEMORY_SIZE 大于等于租户在该物理机上当前的实际使用内存（MEM_USED）。如果调整时 MEMORY_SIZE 的值小于 MEM_USED，则本次调整会失败，需要进行一轮转储释放内存后再重新尝试。因此进行租户缩容前，建议先手动触发一轮转储。

体验租户水平扩缩容

当单节点的资源规格已达上限时，可以通过增加 Unit Number 来增加服务节点，提升租户的总服务能力。租户总服务能力近似为：单 Unit 规格 × Unit Number。

从 V4.0.0 版本开始，OceanBase 数据库要求租户内每个 Zone 的 Unit 个数必须保持一致。为了统一管理各个 Zone 的 Unit，系统引入了 Unit Group 机制：不同 Zone 之间相同编号（UNIT_GROUP_ID）的 Unit 属于同一个 Unit Group。调大或调小 Unit Number 本质上是以 Unit Group 为单位创建和删除 Unit。

操作方法（多节点集群）

以将租户 mysql001 的 Unit Number 从 1 调整为 2 为例：

1. 查看租户当前的 Unit Number：

   obclient [oceanbase]> SELECT TENANT_ID, TENANT_NAME, UNIT_NUM FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_NAME='mysql001';
   

   返回结果中 UNIT_NUM 的值为 1 表示租户的 Unit Number 数为 1。

2. 将 Unit Number 调整为 2：

   obclient [oceanbase]> ALTER RESOURCE TENANT mysql001 UNIT_NUM = 2;
   

   语句执行后，系统会在每个 Zone 上新增一个 Unit，与原有 Unit 组成新的 Unit Group，并将数据通过负载均衡分布到新的 Unit 上。

3. 查看任务的执行状态：

   obclient [oceanbase]> SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE JOB_TYPE='ALTER_RESOURCE_TENANT_UNIT_NUM' AND TENANT_ID=1006;
   

   返回结果中对应记录的 JOB_STATUS 为 SUCCESS 时，表示调整成功。可通过 START_TIME（任务发起时间）、SQL_TEXT（任务对应的 SQL 语句）和 EXTRA_INFO（变更前后的 Unit Number 数）字段定位本次变更记录，示例中的 TENANT_ID、UNIT_GROUP_ID 取值以实际环境查询结果为准。

4. 查看租户的 Unit 分布，确认每个 Zone 的 Unit 个数已变为 2：

   obclient [oceanbase]> SELECT UNIT_ID, ZONE, SVR_IP, UNIT_GROUP_ID, STATUS FROM oceanbase.DBA_OB_UNITS WHERE TENANT_ID=1006;
   

调小 Unit Number 同样使用 ALTER RESOURCE TENANT 语句，系统会随机指定一个 Unit Group，将该 Unit Group 上的数据重新分布到其他 Unit Group 上后再删除该 Unit Group；也可以通过 DELETE UNIT_GROUP 指定要删除的 Unit Group：

-- 随机删除一个 Unit Group，将 Unit Number 调整为 1
obclient [oceanbase]> ALTER RESOURCE TENANT mysql001 UNIT_NUM = 1;

-- 指定删除 UNIT_GROUP_ID 为 1006 的 Unit Group
obclient [oceanbase]> ALTER RESOURCE TENANT mysql001 UNIT_NUM = 1 DELETE UNIT_GROUP =(1006);

集群扩容

当集群整体的存储空间或计算能力不足时，可以向集群中添加 OBServer 节点。以在 zone1 中添加一个节点为例，在 sys 租户中执行：

obclient [oceanbase]> ALTER SYSTEM ADD SERVER 'server_ip:port_num' ZONE 'zone1';

其中 server_ip 为待添加节点的 IP 地址，port_num 为节点的 RPC 端口号（默认为 2882）。新节点添加完成后，Root Service 会自动将现有数据逐步均衡到新节点上，实现存储空间与计算能力的水平扩展，整个扩容过程对业务透明。

对于使用 OBD 管理的集群，还可以使用 obd cluster scale_out 命令完成扩容：创建仅包含新节点信息的配置文件并执行该命令，OBD 会自动完成新节点的部署与注册。

扩缩容验证方法汇总

无论采用哪种扩缩容方式，都可以通过以下系统视图验证变更结果：

下一步

完成本文的水平扩展与弹性伸缩体验后，您可以继续以下探索之旅：

1. 体验并行导入与高压缩：使用并行导入能力完成大批量入库，并对比压缩前后的存储占用，参见 体验并行导入与高压缩。
2. 体验数据保护与恢复：通过闪回查询体验误操作的数据恢复能力，参见 体验数据保护与恢复。
3. 深入多租户与资源隔离：了解多租户架构下的资源管理与隔离机制，参见 体验多租户与资源隔离。

相关文档

• 租户扩缩容的两种途径介绍请参见 租户扩缩容介绍。
• 通过调整资源规格实现租户扩缩容的完整操作请参见 通过调整资源规格实现租户扩缩容。
• 通过调整 Unit Number 实现租户扩缩容的完整操作请参见 通过调整 Unit Number 实现租户扩缩容。
• 资源配置（Unit Config）与资源池（Resource Pool）的概念说明请参见 租户的资源管理。
• 手动向集群添加节点的方法请参见 添加节点。
• 使用 OBD 为集群扩容（obd cluster scale_out）的操作请参见 扩容与组件变更。
• 视图的详细字段说明请参见 GV$OB_UNITS、GV$OB_SERVERS 和 DBA_OB_TENANT_JOBS。
• OBD 测试命令的详细参数请参见 测试命令组。