体验多租户与资源隔离

多租户是 OceanBase 数据库区别于传统单实例数据库的核心能力。OceanBase 采用单集群多租户架构，在集群层面实现了实例资源的池化，每一个租户即一个实例（类比 MySQL Instance），租户与租户之间数据、权限、资源完全隔离，每个租户拥有独立的用户体系及专属的 CPU、内存等资源。通过多租户机制，一个集群可以同时承载多个业务，在保证可用性和性能的前提下高效利用资源，并做到按需弹性扩缩容。

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

• 理解多租户架构：掌握资源配置（Unit Config）、资源池（Resource Pool）、资源单元（Unit）与租户（Tenant）的基本关系。
• 创建不同业务租户：为不同业务创建相互隔离的租户，并配置不同的 CPU、内存、存储等资源规格。
• 验证租户间隔离性：在不同租户中执行查询，观察数据与权限的边界。
• 在线调整资源规格：体验租户资源的在线扩缩容，变更过程对业务无感知。
• 压测观察租户性能：在业务租户中执行标准压测，验证租户可正常承载业务流量，并理解资源配额的隔离逻辑。

前提条件

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

多租户架构简介

OceanBase 数据库通过租户实现资源隔离，让每个数据库服务的实例不感知其他实例的存在，并通过权限控制确保租户数据的安全性。租户是一个逻辑概念，既是各类数据库对象的容器，又是资源（CPU、Memory、IO 等）的容器，在一定程度上相当于传统数据库的"实例"概念。

OceanBase 使用以下三个概念对各租户的可用资源进行管理：

由于分布式的架构，一个 OceanBase 租户可以在资源规格、资源池、副本类型、副本分布几个维度灵活定义，因此创建租户时需要按照 资源配置 → 资源池 → 租户 的顺序进行创建和定义：

资源配置（Unit Config）──> 资源池（Resource Pool）──> 租户（Tenant）
     定义规格                  组合资源单元              分配给业务

创建不同业务租户

以下示例模拟一个集群同时承载两个业务的场景：为业务 A 创建规格较小的租户 tenant1，为业务 B 创建规格较大的租户 tenant2，两者共享集群资源但相互隔离。

操作步骤

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

   obclient -h127.0.0.1 -uroot@sys -P2881 -p -A oceanbase
   

2. 创建两个资源配置。以下示例分别创建 1C2G 和 2C4G 的资源单元规格，您可根据机器实际配置调整：

   obclient [oceanbase]> CREATE RESOURCE UNIT unit1 MAX_CPU=1, MIN_CPU=1, MEMORY_SIZE='2G';
   obclient [oceanbase]> CREATE RESOURCE UNIT unit2 MAX_CPU=2, MIN_CPU=2, MEMORY_SIZE='4G';
   

   命令中的关键参数说明：

   参数	说明
   MAX_CPU	资源单元能够提供的 CPU 上限。必选参数。
   MIN_CPU	资源单元能够提供的 CPU 下限，默认等于 MAX_CPU。
   MEMORY_SIZE	资源单元能够提供的内存规格。必选参数。
   LOG_DISK_SIZE	日志盘空间，默认等于 3 倍内存大小，最小为 2G。
   MAX_IOPS / MIN_IOPS	资源单元可提供的 IOPS 上下限，最小值均为 1024，未指定时默认为 INT64_MAX。

3. 创建资源池并关联资源配置。单节点集群的 ZONE_LIST 为 ('zone1')：

   obclient [oceanbase]> CREATE RESOURCE POOL pool1 UNIT='unit1', UNIT_NUM=1, ZONE_LIST=('zone1');
   obclient [oceanbase]> CREATE RESOURCE POOL pool2 UNIT='unit2', UNIT_NUM=1, ZONE_LIST=('zone1');
   

   命令中的关键参数说明：

   参数	说明
   UNIT	为资源池指定的资源配置，资源池下的每个资源单元均使用该规格。
   UNIT_NUM	资源池在 ZONE_LIST 内每个 Zone 上创建的资源单元个数。
   ZONE_LIST	资源池的使用范围，指定在哪些 Zone 上创建资源单元。

4. 分别创建租户 tenant1 和 tenant2，并关联对应的资源池：

   obclient [oceanbase]> CREATE TENANT IF NOT EXISTS tenant1 CHARSET='utf8mb4', PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool1') SET ob_tcp_invited_nodes='%';
   
   obclient [oceanbase]> CREATE TENANT IF NOT EXISTS tenant2 CHARSET='utf8mb4', PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('pool2') SET ob_tcp_invited_nodes='%';
   

   命令中的关键参数说明：

   参数	说明
   CHARSET	租户的字符集，本例设置为 utf8mb4。
   PRIMARY_ZONE	租户的 Leader 副本优先分布的 Zone。
   RESOURCE_POOL_LIST	租户关联的资源池列表。
   ob_tcp_invited_nodes	租户访问白名单，'%' 表示任意 IP 均可访问，后期可修改。

5. 确认租户创建成功：

   obclient [oceanbase]> SELECT TENANT_ID, TENANT_NAME, TENANT_TYPE, STATUS, TENANT_ROLE
                       FROM DBA_OB_TENANTS WHERE TENANT_TYPE = 'USER';
   

   返回结果示例如下，tenant1 和 tenant2 的 STATUS 均为 NORMAL，表示租户创建成功：

   +-----------+-------------+-------------+--------+-------------+
   | TENANT_ID | TENANT_NAME | TENANT_TYPE | STATUS | TENANT_ROLE |
   +-----------+-------------+-------------+--------+-------------+
   |         1 | sys         | SYS         | NORMAL | PRIMARY     |
   |      1002 | tenant1     | USER        | NORMAL | PRIMARY     |
   |      1004 | tenant2     | USER        | NORMAL | PRIMARY     |
   +-----------+-------------+-------------+--------+-------------+
   3 rows in set
   

   其中 TENANT_ID 等编号由系统自动分配，因环境而异。每个用户租户创建时，系统还会自动创建一个 META$ 开头的内部租户（TENANT_TYPE 为 META），用于管理租户元数据，使用 SELECT * FROM DBA_OB_TENANTS; 查询全量信息时可见，无需关注。

6. 使用 root 用户登录 tenant1，新创建的租户 root 用户默认密码为空，提示输入密码时直接回车即可：

   obclient -h127.0.0.1 -uroot@tenant1 -P2881 -p -A test
   

   登录后执行 SHOW DATABASES;，可以看到新租户拥有独立的数据库列表：

   +--------------------+
   | Database           |
   +--------------------+
   | information_schema |
   | mysql              |
   | oceanbase          |
   | test               |
   +--------------------+
   4 rows in set
   

   与 sys 租户类似，tenant1 内也有 information_schema、mysql、oceanbase 三个系统库，用于存放数据库的系统信息和元数据，请勿在其中存储业务数据。

体验租户间隔离

多租户架构下，租户与租户之间的数据、权限完全隔离：OceanBase 不允许跨租户的数据访问，每个租户拥有独立的用户体系。本节通过两组操作直观验证隔离性。

数据隔离

1. 在 tenant1 中创建一张测试表并插入数据：

   obclient -h127.0.0.1 -uroot@tenant1 -P2881 -p -A test
   

   obclient [test]> CREATE TABLE business_a_order (id INT PRIMARY KEY, item VARCHAR(50), amount DECIMAL(10,2));
   Query OK, 0 rows affected
   
   obclient [test]> INSERT INTO business_a_order VALUES (1, 'keyboard', 149.00);
   Query OK, 1 row affected
   
   obclient [test]> SHOW TABLES;
   +------------------+
   | Tables_in_test   |
   +------------------+
   | business_a_order |
   +------------------+
   1 row in set
   

2. 使用 root 用户登录 tenant2，查看 test 库中的表：

   obclient -h127.0.0.1 -uroot@tenant2 -P2881 -p -A test
   

   obclient [test]> SHOW TABLES;
   Empty set
   

   tenant2 中看不到 tenant1 创建的任何表。两个租户拥有各自独立的 test 库，数据完全隔离。

权限隔离

每个租户拥有独立的用户体系，一个租户中创建的用户无法登录另一个租户。

1. 在 tenant1 中创建业务用户：

   obclient [test]> CREATE USER app_user IDENTIFIED BY '******';
   Query OK, 0 rows affected
   

2. 尝试使用 app_user 连接 tenant2（提示输入密码时输入 app_user 的密码）：

   obclient -h127.0.0.1 -uapp_user@tenant2 -P2881 -p -A test
   Enter password:
   ERROR 1045 (42000): Access denied for user 'app_user'@'xxx.xxx.xxx.xxx' (using password: NO)
   

   连接失败并报 ERROR 1045 Access denied，这是因为 app_user 只存在于 tenant1 的用户体系中，tenant2 无法识别该用户。报错末尾的 using password: NO 表示该用户在 tenant2 中不存在，并非提示您未输入密码。同理，tenant1 的 root 用户与 tenant2 的 root 用户也是两个完全独立的账号。

在线调整租户资源规格

OceanBase 数据库可以灵活地对租户的 CPU、内存资源进行调整，并且在线生效、对业务透明。修改租户所占用的 CPU、内存大小，仅需调整租户所对应的资源配置，不需要对资源池或租户进行调整。

操作步骤

1. 在 sys 租户中查看当前资源配置：

   obclient [oceanbase]> SELECT UNIT_CONFIG_ID, NAME, MAX_CPU, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE
                       FROM oceanbase.DBA_OB_UNIT_CONFIGS WHERE NAME IN ('unit1', 'unit2');
   

   返回结果示例如下：

   +----------------+-------+---------+---------+-------------+---------------+
   | UNIT_CONFIG_ID | NAME  | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE |
   +----------------+-------+---------+---------+-------------+---------------+
   |           1006 | unit1 |       1 |       1 |  2147483648 |    6442450944 |
   |           1007 | unit2 |       2 |       2 |  4294967296 |   12884901888 |
   +----------------+-------+---------+---------+-------------+---------------+
   2 rows in set
   

   查询结果显示，unit1 资源单元的 CPU、内存分别为 1C、2G，日志盘空间为 6G（默认等于 3 倍内存大小）。UNIT_CONFIG_ID 为系统自动分配的编号，因环境而异；MEMORY_SIZE、LOG_DISK_SIZE 的单位为字节，可按 1G = 1073741824 字节换算。

2. 将 unit1 的规格在线调整为 2C、4G，模拟业务 A 的资源扩容：

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

3. 再次查询资源配置，确认调整已生效（重复步骤 1 中的查询语句即可）：

   obclient [oceanbase]> SELECT UNIT_CONFIG_ID, NAME, MAX_CPU, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE
                       FROM oceanbase.DBA_OB_UNIT_CONFIGS WHERE NAME IN ('unit1', 'unit2');
   

   返回结果中 unit1 的 MAX_CPU 和 MIN_CPU 已变为 2，MEMORY_SIZE 已变为 4294967296（即 4G）。LOG_DISK_SIZE 保持不变，ALTER 语句仅调整显式指定的选项，如需同时调整日志盘规格，可在语句中一并指定 LOG_DISK_SIZE：

   +----------------+-------+---------+---------+-------------+---------------+
   | UNIT_CONFIG_ID | NAME  | MAX_CPU | MIN_CPU | MEMORY_SIZE | LOG_DISK_SIZE |
   +----------------+-------+---------+---------+-------------+---------------+
   |           1006 | unit1 |       2 |       2 |  4294967296 |    6442450944 |
   |           1007 | unit2 |       2 |       2 |  4294967296 |   12884901888 |
   +----------------+-------+---------+---------+-------------+---------------+
   2 rows in set
   

4. 通过 GV$OB_UNITS 视图查看资源单元在节点上的分布及实际生效情况：

   obclient [oceanbase]> SELECT SVR_IP, UNIT_ID, TENANT_ID, ZONE, MAX_CPU, MIN_CPU, MEMORY_SIZE, STATUS
                       FROM oceanbase.GV$OB_UNITS;
   

   返回结果示例如下（10.10.10.1 为示例 IP，实际显示为您的本机 IP；UNIT_ID、TENANT_ID 因环境而异，可与前文“确认租户创建成功”步骤中查询到的 TENANT_ID 对应）：

   +------------+---------+-----------+-------+---------+---------+-------------+--------+
   | SVR_IP     | UNIT_ID | TENANT_ID | ZONE  | MAX_CPU | MIN_CPU | MEMORY_SIZE | STATUS |
   +------------+---------+-----------+-------+---------+---------+-------------+--------+
   | 10.10.10.1 |       1 |         1 | zone1 |       2 |       2 |  1073741824 | NORMAL |
   | 10.10.10.1 |    1002 |      1001 | zone1 |    NULL |    NULL |  1073741824 | NORMAL |
   | 10.10.10.1 |    1002 |      1002 | zone1 |       2 |       2 |  3221225472 | NORMAL |
   | 10.10.10.1 |    1003 |      1003 | zone1 |    NULL |    NULL |  1073741824 | NORMAL |
   | 10.10.10.1 |    1003 |      1004 | zone1 |       2 |       2 |  3221225472 | NORMAL |
   +------------+---------+-----------+-------+---------+---------+-------------+--------+
   5 rows in set
   

   返回结果中，每个资源单元对应一行记录：TENANT_ID 为 1 的行是 sys 租户的资源单元；MAX_CPU 为 NULL 的行是内部 Meta 租户的资源记录；其余两行分别是 tenant1 和 tenant2 的资源单元，STATUS 为 NORMAL 表示资源单元状态正常。视图中的 MEMORY_SIZE 为扣除系统预留后的实际生效额度，会小于配置值（例如 4G 规格显示为 3221225472，约 3G）。

资源变更方式对比

除直接修改资源配置外，OceanBase 还支持通过切换资源配置、调整 UNIT_NUM、变更 ZONE_LIST 等方式进行租户资源变更，分别适用于不同的扩缩容场景（后两种适用于多 Zone、多节点集群，单节点环境无法演示）：

压测观察租户性能

完成前两节的操作后，tenant1（1C2G）和 tenant2（2C4G）两个业务租户已就绪。本节使用 sysbench 对租户执行标准点查压测，验证新租户可正常承载业务流量，并结合结果理解 OceanBase 的资源隔离逻辑。

操作步骤

1. 对小规格租户 tenant1 发起点查压测（如已按上一节将 unit1 调整为 2C4G，可先执行 ALTER RESOURCE UNIT unit1 MAX_CPU=1, MIN_CPU=1, MEMORY_SIZE='2G'; 调回）：

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

   首次执行时，obd 会自动完成测试数据生成、数据加载和压测执行，结束后输出 QPS、延迟等统计结果，记录其中的 QPS 和 95% 延迟。

2. 对大规格租户 tenant2（2C4G）执行完全相同参数的压测：

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

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

   • 两轮压测均正常结束并输出统计结果，说明两个租户均可独立承载业务流量；
   • 压测数据在各租户中独立生成，tenant1 的压测不会在 tenant2 中留下数据。

结果解读

两轮压测的 QPS 数值因机器规格、数据量、并发参数不同而差异较大，无需关注绝对值，重点观察以下现象：

下一步

完成本文的多租户与资源隔离体验后，您可以继续以下探索之旅：

1. 体验高可用与故障切换：了解 OceanBase 的副本、Zone、Leader/Follower 等核心概念，观察副本与 Leader 分布，体验故障场景下的服务连续性，参见 体验高可用与故障切换。
2. 体验水平扩展与弹性伸缩：探索计算、存储和租户资源层面的扩展能力，观察扩容前后的资源变化与业务容量影响，参见 体验水平扩展与弹性伸缩。
3. 体验租户内资源隔离：在同一租户内通过资源组隔离 TP 与 AP 负载，参见 体验 HTAP 混合负载场景。

相关文档

• 多租户特性的完整体验流程请参见 体验多租户特性。
• 多租户架构的基本概念请参见 多租户架构概述。
• 租户资源管理（资源配置、资源池、资源单元）的详细说明请参见 租户的资源管理。
• 查看租户资源配置的方法请参见 查看资源规格。
• 删除租户的语法说明请参见 DROP TENANT。
• 租户内资源隔离（资源组）的配置方法请参见 配置租户内资源隔离。
• OBD 测试命令的详细参数请参见 测试命令组。