---
title: "集群架构 - OceanBase 数据库 V4.3.5 | OceanBase 文档中心"
description: 集群架构 基本概念 集群 OceanBase 集群由一个或多个 Region 组成，Region 由一个或多个 Zone 组成，Zone 由一个或多个 OBServer 组成，每个 OBServer 可有若干个 Unit，每个 Unit 可有若干个日志流（Logstream）的副本（Replica），每个 Logst…
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.3.5 LTS

# 集群架构

更新时间：2026-04-07 20:57:20

[编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.3.5/zh-CN/700.reference/100.oceanbase-database-concepts/500.distributed-database-objects/200.cluster-architecture.md)  

## 基本概念

### 集群

OceanBase 集群由一个或多个 Region 组成，Region 由一个或多个 Zone 组成，Zone 由一个或多个 OBServer 组成，每个 OBServer 可有若干个 Unit，每个 Unit 可有若干个日志流（Logstream）的副本（Replica），每个 Logstream 可使用若干个分片（Tablet）。

### Region

Region 对应物理上的一个城市或地域，当 OceanBase 集群由多个 Region 组成时，数据库的数据和服务能力就具备地域级容灾能力；当集群只有一个 Region 时，如果出现整个城市级别的故障，则会影响数据库的数据和服务能力。

### Zone

在 OceanBase 数据库中，Zone 是指一个数据中心或一个物理区域，它是一个逻辑上的概念，通常包含多个存储节点，这些节点在物理上可以分布在不同的机房、不同的机架或不同的服务器上。一个 Zone 可以包含多个数据中心（比如机房），但是一个数据中心只能属于一个 Zone。

在 OceanBase 数据库中，Zone 通常用于实现跨数据中心的数据容灾。OceanBase 会将数据按照一定的规则分布到不同的 Zone 中，从而实现数据的冗余备份。当一个 Zone 发生故障时，系统可以自动切换到备用 Zone 中的数据来保证数据的可用性。

除了数据容灾，OceanBase 数据库的 Zone 还可以用于数据分片的容器。数据分片是一种将数据划分为多个分片，并将不同分片存储在不同的节点上的技术，可以提高系统的吞吐量和性能。在 OceanBase 数据库中，可以将不同的 Zone 作为不同的分片的 Primary Zone，从而实现分布式存储和处理数据。

### OBServer

运行 observer 进程的物理机。一台物理机上可以部署一个或者多个 OBServer（通常情况下一台物理机只部署一个 OBServer）。在 OceanBase 数据库内部，Server 由其 IP 地址及服务端口唯一标识。

### Unit

租户在 OBServer 节点上的容器，描述租户在 OBServer 上的可用资源（CPU、MEMORY 等）。一个租户在一个 OBServer 只能同时存在一个 Unit。

### Partition

分区（Partition）是用户创建的逻辑对象，是划分和管理表数据的一种机制。用户可以进行多种分区管理操作，包括：创建、删除、Truncate、分裂、合并、交换等。

### Tablet

OceanBase 数据库 V4.0.0 版本引入了分片（Tablet） 概念来表示实际的数据存储对象。它具备存储数据的能力，支持在机器之间迁移（Transfer），是数据均衡的最小单位。Tablet 与分区一一对应，单分区表会创建一个Tablet，多分区表会为每个分区创建一个 Tablet。索引表的每个分区也会对应一个 Tablet，包括局部索引表和全局索引表。特别地，局部索引表的 Tablet 与主表 Tablet 会强制绑定，保证存储在一台机器上。

### Logstream

日志流（Logstream，LS）是由 OceanBase 数据库自动创建和管理的实体，它代表了一批数据的集合，包括若干 Tablet 和有序的 Redo 日志流。它通过 Paxos 协议实现了多副本日志同步，保证副本间数据的一致性，实现了数据的高可用。日志流副本支持在不同机器之间迁移（Migration）和复制（Replication），以达到机器管理和系统容灾的目的。

从数据存储的角度来看，日志流可以抽象为 Tablet 容器，支持添加和管理 Tablet 数据，允许 Tablet 在不同日志流之间转移（Transfer），以达到数据均衡和水平扩展的目的。

从事务的角度来看，日志流是事务的提交单位。事务修改在单个日志流内完成时可以采用一阶段原子提交；事务修改跨多个日志流时，采用 OceanBase 数据库优化的两阶段提交协议完成原子提交，日志流是分布式事务参与者。

## 部署模式

为保证单一机器故障时同一分区的多数派副本可用，OceanBase 数据库会保证同一个分区的多个副本不调度在同一台机器上。由于同一个分区的副本分布在不同的 Zone/Region 下，在城市级灾难或者数据中心故障时既保证了数据的可靠性，又保证了数据库服务的可用性，达到可靠性与可用性的平衡。OceanBase 数据库创新的容灾能力有三地五中心可以无损容忍城市级灾难，以及同城三中心可以无损容忍数据中心级故障。

**三地五中心部署**

![部署1](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/6263623461/p351254.jpg)

**同城三中心部署**

![部署2](https://help-static-aliyun-doc.aliyuncs.com/assets/img/zh-CN/6263623461/p351256.jpg)

OceanBase 数据库的无损容灾能力还可以方便集群的运维操作，当数据中心或者服务器需要替换和维修时，可以直接下线对应的数据中心或服务器进行替换和维修，并补充进新的数据中心或服务器，OceanBase 数据库会自动进行日志流副本的复制和均衡，整个过程可以保证数据库服务的使用不受影响。

## RootService

OceanBase 数据库集群会有一个总控服务（RootService），其运行在某个 OBServer上。当 RootService 所在机器故障时，其余 OBServer 会选举出来新的 RootService。RootService 主要提供资源管理、容灾、负载均衡、schema 管理等功能，其中：

- 资源管理

  包括 Region/Zone/OBServer/Resource Pool/Unit 等元信息的管理，比如：上下线 OBServer、改变 Tenant 资源规格等。
 - 负载均衡

  决定 Unit 在多个机器间的分布。
 - 容灾

  通过自动复制、迁移等手段，保证日志流分布和类型与用户指定的 Locality 最终保持一致。
 - Schema 管理

  负责处理 DDL 请求并生成新 Schema。

## Locality

租户下日志流在各个 Zone 上的副本分布和类型称为 Locality。我们可以通过建租户指定 Locality 的方式决定租户下日志流初始的副本类型和分布，后续可通过改变租户 Locality 的方式进行修改。

下边的语句表示创建 `mysql_tenant`租户，并且其租户下的日志流在 `z1`、`z2`、`z3` 上都是全能型副本。

```sql
obclient> CREATE TENANT mysql_tenant RESOURCE_POOL_LIST =('resource_pool_1'), primary_zone = "z1;z2;z3", locality ="F@z1, F@z2, F@z3" setob_tcp_invited_nodes='%';

```

下边的语句表示变更 mysql_tenant 的 Locality，使其租户下的日志流在 z1、z2 是全能型副本，z3 是日志型副本。OceanBase 数据库会基于租户新旧 Locality 的对比，决定是否创建/删除/转换对应 Zone 的副本。

```sql
ALTER TENANT mysql_tenant set locality = "F@z1, F@z2, L@z3";

```

- 每一个日志流在同一个 OBServer 节点中有且仅有一个副本。
 - 对于一个日志流而言，其在一个 Zone 内最多存在一个 Paxos 副本，可以有若干个非 Paxos 副本。可以在 Locality 中指定非 Paxos 副本，如：

     - `locality = "F{1}@z1, R{1}@z1"`：表示 z1 有 1 个全能型副本，1 个只读型副本。
     - `locality = "F{1}@z1, R{ALL_SERVER}@z1"`: 表示 z1 有一个全能型副本，并在同 Zone 其余机器上创建只读型副本（可以没有只读型副本）。

RootService 会根据用户设置的 Locality，通过副本创建/删除/迁移/类型转换的方式，使日志流的副本分布和类型满足用户配置的 Locality。

## Primary Zone

用户可通过一个租户级的配置，使租户下日志流的 Leader 分布在指定的 Zone 上，此时称 Leader 所在的 Zone 为 Primary Zone。

Primary Zone 是一个 Zone 集合，用分号（;）分割表示不同的优先级，用逗号（,）分隔表示相同的优先级。RootService 会根据用户设置的 Primary Zone，按照优先级高低顺序，尽可能把日志流的 Leader 调度到更高优先级的 Zone 内，并在同一优先级的 Zone 间将 Leader 打散在不同的机器上。不设置 Primary Zone 的场合，会认为租户的所有 Zone 都是同一优先级，RootService 会把租户日志流的 Leader 打散在所有 Zone 内的机器。

用户可通过租户级配置，设置或修改租户的 Primary Zone。

示例如下：

- 租户创建时设置 Primary Zone，优先级 `z1` = `z2` > `z3`。

  ```sql
  obclient> CREATE TENANT mysql_tenant RESOURCE_POOL_LIST =('resource_pool_1'), primary_zone = "z1,z2;z3", locality ="F@z1, F@z2, F@z3" setob_tcp_invited_nodes='%';

  ```
 - 变更租户 Primary Zone，优先级 `z1` > `z2` > `z3`。

  ```sql
  obclient> ALTER TENANT mysql_tenant set primary_zone ="z1;z2;z3";

  ```
 - 变更租户 Primary Zone，优先级 `z1` = `z2` = `z3`。

  ```sql
  obclient> ALTER TENANT mysql_tenant set primary_zone =RANDOM;

  ```

#### 说明

Primary Zone 只是其中一种选主参考因素，日志流对应 Zone 的副本是否能成为 Leader 还需要参考副本类型、日志同步进度等因素。

  上一篇 下一篇 ![有帮助](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) 咨询热线