集群架构

基本概念

集群

OceanBase 数据库集群由一个或多个 Region 组成，Region 由一个或多个 Zone 组成，Zone 由一个或多个 OBServer 组成，每个 OBServer 可有若干个 Unit，每个 Unit 可有若干个日志流 Logstream 的 Replica，每个 Logstream 可使用若干个 Tablet。

Region

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

Zone

Zone 一般情况（不考虑机房级容灾可部署一中心三副本）下对应一个有独立网络和供电容灾能力的数据中心，在一个 Region 内的多个 Zone 间 OceanBase 数据库集群拥有 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

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

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

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

部署模式

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

三地五中心部署

同城三中心部署

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 上都是全能型副本。

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 的副本。

ALTER TENANT mysql_tenant set locality = "F@z1, F@z2, LR@z3";

• 每一个日志流在同一个 OBServer 中有且仅有一个副本。

• 对于一个日志流而言，其在一个 Zone 内最多存在一个 Paxos 副本，可以有若干个非 Paxos 副本。可以在 Locality 中指定非 Paxos 副本，如：

  • locality = "F{1}@z1, R{2}@z1"：表示 z1 有 1 个全能型副本，2 个只读型副本。

  • 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。

  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。

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

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

  obclient> ALTER TENANT mysql_tenant set primary_zone =RANDOM;
  

说明

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