---
title: 创建的表 Leader 始终分布在同一个 observer-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于创建的表 Leader 始终分布在同一个 observer相关的常见问题和使用技巧，帮助您快速解决创建的表 Leader 始终分布在同一个 observer的难题。
---
切换语言

- 简体中文
- English

划线反馈

# 创建的表 Leader 始终分布在同一个 observer

更新时间：2026-05-26 06:26

适用版本： V4.0.x、V4.1.x、V4.2.x、V4.3.x、V4.4.x 内容类型：Troubleshoot  

## 问题现象

集群从 1-1-1 通过 ob-operator 扩容到 2-2-2 拓扑后，在新建租户下创建副本集表或分区表，leader 角色的 tablet 始终分布在 primary zone 的同一个 observer 上，其 LS_ID 为 0。租户设置的 leader zone 是 zone1，期望新创建的 tablet 的 leader 能均衡分配在 zone1 的 observer1 或 observer2，以均衡利用两个 observer 的资源。

## 问题原因

### 排查步骤

1. 查询建表语句：

   ```sql
   CREATE TABLE IF NOT EXISTS test.tb1 (
     id INT PRIMARY KEY,
     f1 VARCHAR(255),
     f2 VARCHAR(255),
     f3 VARCHAR(255),
     f4 VARCHAR(255),
     f5 VARCHAR(255)
   ) DUPLICATE_SCOPE = 'cluster'
   PARTITION BY hash(id + 1) PARTITIONS 4;

   ```
 2. 在业务租户下查询表位置信息：

   ```sql
   SELECT A.duplicate_scope, B.flag
   FROM oceanbase.DBA_OB_TABLE_LOCATIONS AS A
   JOIN oceanbase.DBA_OB_LS AS B ON A.ls_id = B.ls_id
   WHERE A.table_name = 'tb1'
   AND A.role = 'LEADER';

   ```

   返回结果如下：

   ```text
   +-----------------+-----------+
   | duplicate_scope | flag      |
   +-----------------+-----------+
   | CLUSTER         | DUPLICATE |
   | CLUSTER         | DUPLICATE |
   | CLUSTER         | DUPLICATE |
   | CLUSTER         | DUPLICATE |
   +-----------------+-----------+

   ```
 3. 在 sys 租户查询表位置详情：

   ```sql
   SELECT * FROM oceanbase.CDB_OB_TABLE_LOCATIONS
   WHERE table_name = 'tb1'
   LIMIT 4;

   ```

   返回结果如下：

   ```text
   +-----------+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+----------------+----------+--------+--------------+-----------------+----------------------------+-----------+-----------------+---------------+----------+
   | TENANT_ID | DATABASE_NAME | TABLE_NAME | TABLE_ID | TABLE_TYPE | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | DATA_TABLE_ID | TABLET_ID | LS_ID | ZONE  | SVR_IP         | SVR_PORT | ROLE   | REPLICA_TYPE | DUPLICATE_SCOPE | DUPLICATE_READ_CONSISTENCY | OBJECT_ID | TABLEGROUP_NAME | TABLEGROUP_ID | SHARDING |
   +-----------+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+----------------+----------+--------+--------------+-----------------+----------------------------+-----------+-----------------+---------------+----------+
   |      1006 | test          | tb1        |   500002 | USER TABLE | p0             | NULL              | NULL       |          NULL |    200001 |  1003 | zone1 | xxx.xxx.xxx.55 |     2882 | LEADER | FULL         | CLUSTER         | STRONG                     |    500003 | NULL            | NULL          | NULL     |
   |      1006 | test          | tb1        |   500002 | USER TABLE | p1             | NULL              | NULL       |          NULL |    200002 |  1003 | zone1 | xxx.xxx.xxx.55 |     2882 | LEADER | FULL         | CLUSTER         | STRONG                     |    500004 | NULL            | NULL          | NULL     |
   |      1006 | test          | tb1        |   500002 | USER TABLE | p2             | NULL              | NULL       |          NULL |    200003 |  1003 | zone1 | xxx.xxx.xxx.55 |     2882 | LEADER | FULL         | CLUSTER         | STRONG                     |    500005 | NULL            | NULL          | NULL     |
   |      1006 | test          | tb1        |   500002 | USER TABLE | p3             | NULL              | NULL       |          NULL |    200004 |  1003 | zone1 | xxx.xxx.xxx.55 |     2882 | LEADER | FULL         | CLUSTER         | STRONG                     |    500006 | NULL            | NULL          | NULL     |
   +-----------+---------------+------------+----------+------------+----------------+-------------------+------------+---------------+-----------+-------+-------+----------------+----------+--------+--------------+-----------------+----------------------------+-----------+-----------------+---------------+----------+

   ```
 4. 查看日志流信息：

   ```sql
   SELECT TENANT_ID, LS_ID, STATUS, PRIMARY_ZONE, UNIT_GROUP_ID, LS_GROUP_ID
   FROM oceanbase.CDB_OB_LS
   WHERE LS_ID = 1003;

   ```

   返回结果如下：

   ```text
   +-----------+-------+--------+--------------------+---------------+-------------+
   | TENANT_ID | LS_ID | STATUS | PRIMARY_ZONE       | UNIT_GROUP_ID | LS_GROUP_ID |
   +-----------+-------+--------+--------------------+---------------+-------------+
   |      1006 |  1003 | NORMAL | zone1;zone2,zone3  |             0 |           0 |
   +-----------+-------+--------+--------------------+---------------+-------------+

   ```

### 原因分析

根据上述排查结果可知，创建的表是**复制表**（DUPLICATE_SCOPE = 'CLUSTER'）。复制表具有以下特性：

- 创建复制表后，租户的所有 observer 内都会创建一个副本。
 - 所有副本中只有一个副本会被选为 Leader，接受写请求，其余副本只能接受读请求。
 - 复制表使用广播日志流，对应的 `UNIT_GROUP_ID = 0`。

因此，复制表的 Leader 始终位于同一个 observer 上，无法实现负载均衡。

## 解决方案

如需实现 Leader 均衡分布，请创建普通表而非复制表，即在建表时不要指定 `DUPLICATE_SCOPE = 'cluster'` 参数。

## 适用版本

OceanBase 数据库 V4.x 版本。

Previous

[外表支持读取 orc、parquet 格式文件的使用说明](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002342230)

Next

[Queuing 表运行使用机制](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000005428696) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线