OceanBase 核心技术能力

• 完全自主研发：代码级可控，大规模金融场景 10 年可靠性验证
• 原生分布式：全量数据校验实现数据一致性、数据不丢失、高可用、平滑扩展
• 单机分布式一体化：一体化架构突破高性能和高可用，实现应用无限扩展和服务永远在线
• HTAP 混合事务与实时分析处理：一份数据既能做事务处理又能实时分析，通过 HTAP 助力拓展更多可能
• Oracle/MySQL 平滑迁移：平滑迁移快速、最小成本搬迁应用数据
• 高级压缩技术：基于 LSM-Tree 的高压缩引擎，有效降低成本存储 70% - 90%
• 原生多租户：原生多租户，资源隔离按需使用，灵活管理

OceanBase 基本概念

• 集群： OceanBase数据库集群由一个或多个Region组成，Region由一个或多个Zone组成，Zone由一个或多个OBServer组成，每个OBServer有若干个Partition的Replica
• Zone： Zone是集群中的一个逻辑概念，通常对应一个有独立网络和供电容灾能力的数据中心。在多Region部署时，Zone可以对应一个数据中心，具有容灾能力
• OB server： 运行observer进程的物理机，可以部署一个或多个OBServer，每个OBServer由其IP地址和服务端口唯一标识
• 资源池： 资源池包含了资源单元，资源单元规定了具体资源的量化（如CPU、Memory、Disk_Size和IOPS等）。资源池和资源单元用于满足租户资源隔离和负载均衡
• 租户： 类似于传统数据库的数据库实例，拥有一定的资源能力（如CPU、内存和空间）。租户下可以建立数据库，并且可以进行租户级别的转储、分区主切换和扩容缩容
• 分区： OceanBase数据库以分区为单位组织用户数据，分区在不同机器上的数据拷贝称为副本（Replica）。同一分区的多个副本使用Paxos一致性协议保证副本的强一致
• Tablet： 表示实际的数据存储对象，具备存储数据的能力，支持在机器之间迁移，是数据均衡的最小单位。Tablet与分区一一对应，单分区表会创建一个Tablet，多分区表会为每个分区创建一个Tablet
• 日志流： 由OceanBase数据库自动创建和管理的实体，代表了一批数据的集合，包括若干Tablet和有序的Redo日志流。通过Paxos协议实现多副本日志同步，保证副本间数据的一致性
• 副本： 同一日志流的多个数据拷贝，使用Paxos一致性协议保证副本的强一致。每个日志流和它的副本构成一个独立的Paxos组，其中一个日志流为主副本（Leader），其它为从副本（Follower）
• Paxos： 一种分布式选举算法，用于实现高可用和数据一致性。在OceanBase中，Paxos用于保证副本间的日志同步和数据一致性

OceanBase 路由与负载均衡

ODP/OBProxy（OceanBase Database Proxy）介绍

ODP，全称为OceanBase Database Proxy，也被称为OBProxy，是OceanBase数据库的核心组件之一。它是一种数据库代理中间件，主要负责连接池管理、负载均衡、故障转移等功能。OBProxy作为可选组件，其部署取决于应用需求和场景。

核心功能

1. 路由转发 ：OBProxy负责将客户端的SQL请求路由转发到合适的OBServer上，并将执行结果返回。它通过Fast Parser对SQL进行解析，从Cache中获取对象的Schema信息，对于分区表，还需提取相应的分区表达式。路由规则的确定基于多种属性，如强一致性读/弱一致性读、目标OBServer状态、路由精准度、LDC匹配和Zone类型等。
2. 连接管理 ：作为负载均衡代理，OBProxy充当网关，使得OBServer对客户端变得透明。在OBServer宕机、升级或重启时，客户端与OBProxy的连接不会断开，OBProxy可以迅速切换到正常的OBServer上。
3. 运维监控 ：OBProxy定期向OCP上报信息，实现语句、事务、Session和OBProxy级别的各种统计。支持慢查询日志、SQL监控等，便于运维管理。

部署模式

1. 集中部署 ：OBProxy集群形成一个单独的层，前端再做一层负载均衡。
2. 客户端部署 ：每客户端分别部署OBProxy。

启动模式

1. 测试模式 ：用于开发调试，不依赖ConfigServer，可指定集群的RSList（IP列表）启动，OBProxy集群与OB集群一对一。
2. 生产模式 ：通过指定ConfigServer提供的config_url来启动，配置服务可以协助获取集群的配置信息。同一个ConfigServer可以保存多个OB集群的RSList信息，一个OBProxy集群可访问多个OB集群。

高可用和负载均衡

OBProxy本身无状态，支持无限水平扩展，支持同时访问多个OceanBase集群。通过丰富的内部命令对OBProxy状态进行实时监控，使得运维简单便利。OBProxy高可用分为两部分：一方面保证自身高可用，持续提供代理服务；另一方面OBProxy是OceanBase高可用体系的主要组成部分，可以对用户屏蔽宕机、升级等情况，保证OceanBase数据库服务的稳定和快速恢复。

专有协议

OBProxy与OBServer节点默认采用了OceanBase专有协议，如增加报文的CRC校验保证与OBServer节点链路的正确性，增强传输协议以支持Oracle兼容性的数据类型和交互模型。

通过上述功能，ODP/OBProxy在OceanBase数据库系统中扮演着至关重要的角色，确保了系统的高性能、高可用性和易运维性。

Primary Zone 介绍

Primary Zone 是 OceanBase 数据库中用于控制数据副本（Replica）分布和负载均衡的关键特性。它允许数据库管理员指定 Leader 副本的偏好位置，从而影响数据的分布和系统的负载均衡。

基本概念

Primary Zone 表示 Leader 副本的偏好位置。通过设置 Primary Zone，可以指定 Leader 更倾向于被调度到哪个 Zone 上。例如，如果一张表的 Primary Zone 设置为 "zone1"，则 RootService 会尽量将该表的 Leader 调度到 zone1 上。Primary Zone 实际上是一个 Zone 的列表，列表中的 Zone 用  ;  分隔表示从高到低的优先级，用  ,  分隔表示相同优先级。

设置 Primary Zone

Primary Zone 的设置涉及到多个层面，包括 Table 级、TableGroup 级、Database 级以及 Tenant 级。每个级别都可以指定 Primary Zone，如果没有指定，则默认向上继承。Tenant 级别的 Primary Zone 是必须指定的，如果创建时未指定， 默认填写为 RANDOM，表示各个 Zone 优先级相同。

使用方法

数据库管理员可以通过 SQL 语法对 Primary Zone 进行设置或修改。例如，创建租户时指定 Primary Zone：

CREATE TENANT [IF NOT EXISTS] tenant_name PRIMARY_ZONE [=] zone;

或者修改已存在表的 Primary Zone：

ALTER TABLE [SET] PRIMARY_ZONE [=] zone;

示例

假设有三个 Zone 分别位于不同的 Region：sh1, sh2, sh3 在 Region SH，hz1, hz2, hz3 在 Region HZ，sz1, sz2, sz3 在 Region SZ。用户设置的 Primary Zone 为 'sh1;hz1;hz2;sz1'，根据改写规则，最终得到的 Primary Zone 为 'sh1;sh2,sh3;hz1;hz2;hz3;sz1;sz2,sz3'。这意味着 Leader 会优先分布在 sh1 上，如果 sh1 发生故障，Leader 会依次分布在 sh2 和 sh3 上。

继承关系

Primary Zone 的设置遵循一定的继承规则。如果 Table 级的 Primary Zone 未指定，则会查看 TableGroup 的 Primary Zone，如果 TableGroup 也未指定，则查看 Database 的 Primary Zone，最后是 Tenant 级的 Primary Zone。

表组（Tablegroup）介绍

表组（Tablegroup）是OceanBase数据库中用于优化分布式环境下表间关联查询性能的重要特性。它通过将具有相同分区键和分区数量的表组织在一起，减少跨节点的数据访问，从而提高查询效率。

基本概念

在分布式数据库中，数据被分散存储在不同的节点上。当执行涉及多个表的查询时，如果这些表的数据分布在不同的节点上，就需要进行跨节点的数据访问，这会显著增加查询的延迟。表组通过将相关表的数据集中在同一个节点上，减少了这种跨节点的数据访问，从而优化了查询性能。

表组的工作原理

1. 分区策略 ：表组内的表必须具有相同的分区键和分区数量。这样，当数据被分区时，相关表的相应分区可以被分配到同一个节点上。
2. 数据分布 ：OceanBase的RootService会尽量将同一个表组内的表的分区调度到同一个OBServer上，以减少分布式事务的发生概率。
3. 事务处理 ：由于表组内的表的分区尽量分布在同一个节点上，因此，当事务涉及这些表时，可以减少跨节点的事务处理，降低事务的复杂性和延迟。

使用场景

表组特别适用于以下场景：

• 关联查询 ：当多个表经常一起参与查询时，通过表组可以减少跨节点的数据访问，提高查询性能。
• 数据聚合 ：在需要对多个表进行数据聚合操作时，表组可以减少数据在节点间的传输，加快聚合速度。
• 事务处理 ：对于涉及多个表的事务，表组可以减少分布式事务的开销，提高事务处理的效率。

创建和管理表组

在OceanBase中，可以通过以下SQL语句创建表组：

CREATE TABLEGROUP tablegroup_name [BINDING = {TRUE | FALSE}] [PARTITION BY hash (column_list)] PARTITIONS num;

• tablegroup_name  是表组的名称。
• BINDING  指定表组是否绑定，绑定的表组不能被删除，直到所有表都从表组中移除。
• PARTITION BY hash (column_list)  定义了分区策略， column_list  是用于分区的列名。
• PARTITIONS num  指定了分区的数量。

将表加入表组的语句如下：

ALTER TABLE table_name TABLEGROUP tablegroup_name;

示例

假设有两个表  orders  和  order_details ，它们都包含  order_id  作为分区键。创建表组并添加表的示例如下：

CREATE TABLEGROUP order_group BINDING PARTITION BY hash(order_id) PARTITIONS 6;
ALTER TABLE orders TABLEGROUP order_group;
ALTER TABLE order_details TABLEGROUP order_group;

这样， orders  和  order_details  表的分区将尽量被分配到同一个节点上，从而优化了涉及这两个表的查询性能。

RootService 总控服务（RS）

RootService（RS）是OceanBase数据库中的总控服务，它扮演着集群管理和协调的核心角色。RootService负责整个OceanBase集群的管理和协调，包括集群的初始化、启动、关闭，租户的创建、资源分配，以及管理集群中服务器的加入和退出等。它还负责数据表格的创建、删除以及分区的管理和迁移，同时维护集群元数据的一致性和可用性，比如表的元数据、服务器和租户的配置信息。此外，RootService还负责在服务器之间平衡数据和请求的分布。

功能特点

1. 集群自举 ：RootService在集群初始化时发挥关键作用，通过bootstrap操作指定三个节点选举出一个leader，初始化相关内部表，从而启动RootService服务并完成OceanBase集群的搭建。
2. 集群资源管理 ：包括Zone的创建和管理、OBServer节点的生命周期管理，如节点心跳检测、上线和下线、新增和删除等。
3. 集群级别参数变更 ：RootService负责将参数的变更发往各个节点上SQL引擎执行，实现集群级别的参数管理。
4. 集群分区负载均衡 ：计算各个资源单元的负载和节点负载，发起分区迁移任务和分区leader切换任务，以实现负载均衡。
5. 指导分区leader选举 ：RootService根据一些规则（如primary_zone或locality）影响分区的leader选举，确保数据的高可用性。
6. 合并转储冻结管理 ：管理OceanBase的增量数据，当内存使用率超过阈值后，需要冻结、转储到磁盘或者跟基线数据做合并落盘。

高可用性

RootService服务使用Paxos协议实现高可用，可以通过集群配置指定RootService服务副本数。RootService的各副本基于Paxos协议选举leader，leader副本上任后为集群提供RootService服务。当RootService的当前leader发生故障卸任时，其他的RootService副本重新选举产生新的leader，并继续提供RootService服务，实现高可用。

OceanBase 高可用功能介绍

数据库容灾能力指标

在数据库容灾和业务连续性规划中，两个关键的性能指标是恢复点目标（Recovery Point Objective，简称RPO）和恢复时间目标（Recovery Time Objective，简称RTO）。这两个指标帮助企业评估和制定灾难恢复计划，确保在面临灾难时能够最小化数据丢失和业务中断。

RPO（恢复点目标）

RPO是指在灾难发生后，业务系统所能容忍的数据丢失量。它衡量的是容灾系统的数据冗余备份能力，具体来说，RPO是业务系统在灾难过程中允许丢失数据的最大时间长度。RPO的值取决于数据备份的频率和数据复制技术。例如，如果一个企业的RPO为1小时，那么在发生灾难或故障的情况下，该企业可以容忍1小时内的数据丢失。

RTO（恢复时间目标）

RTO是指灾难发生后，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持业务部门运作，业务恢复运营之时，此两点之间的时间。RTO衡量的是业务恢复的及时性，即业务从中断到恢复正常所需的时间。RTO的值越小，代表容灾系统的数据恢复能力越强。

RPO与RTO的关系

RPO和RTO并不是孤立的，而是从不同角度反映数据中心的容灾能力。RPO关注的是数据丢失的容忍度，而RTO关注的是业务恢复的时间。两者的数值越小，就越能有效缩短业务从正常到过渡期的时间间隔。在实际应用中，企业需要根据自身的业务需求和成本效益分析，来确定合适的RPO和RTO值。

OceanBase 仲裁高可用

OceanBase数据库的仲裁高可用（Arbitratrion Service）是一种基于Paxos多副本容灾方案提出的新型高可用方案，它通过引入仲裁节点来增强分布式数据库的容灾能力。这种方案允许在多个数据副本间发生半数异常时，通过集群之外的仲裁服务来参与变更决策，进而恢复服务。自OceanBase数据库V4.1.0版本开始，这一特性得到了支持

仲裁服务的特点

1. 独立部署 ：仲裁服务独立于OceanBase集群部署，作为一个以特殊模式启动的轻量级observer进程，它承载着日志流级别的仲裁成员。
2. 资源开销小 ：仲裁成员仅参与选举、成员变更投票，不参与日志同步投票。它们不存储日志，无MemTable和SSTable，因此资源开销极小。
3. 不能作为主节点 ：仲裁节点不能当选为主提供服务，它们的主要作用是在集群中出现故障时，帮助集群快速恢复。

仲裁服务的应用场景

1. 自动选主提升同城自动容灾能力 ：在同城部署模式下，仲裁服务可以自动选主，提升同城的自动容灾能力。
2. 降低跨城带宽提升两地三中心稳定性 ：在两地三中心部署模式下，仲裁服务可以解决同城副本故障时RT变大的问题，同时有效降低跨城带宽开销，并降低第三机房的部署成本。
3. 成本敏感场景 ：对于成本敏感或预算有限且能承受可能丢失数据的情况，可以选择OceanBase 2F1A仲裁高可用方案。若期望数据不丢失，建议选择全功能型副本高可用方案。

仲裁服务的配置和管理

OceanBase的仲裁服务可以通过OCP（OceanBase Cloud Platform）进行配置和管理，提供仲裁服务的部署、启停、接管、删除、升级等能力，实现了对仲裁服务的全生命周期管理。

OceanBase 故障场景下自动切换 leader

OceanBase数据库的自动切换Leader机制是其高可用性（High Availability, HA）的核心特性之一。在分布式数据库系统中，为了保证服务的连续性和数据的一致性，当某个节点发生故障时，系统需要能够快速地选举出一个新的Leader来接管服务。OceanBase通过Paxos协议和多副本机制，实现了在故障场景下的自动切换Leader，确保了系统的稳定性和数据的安全性。

1. Paxos协议与多副本机制

OceanBase数据库中的每个分区都维护了多个副本，这些分区的多个副本之间通过Paxos协议进行日志同步。每个分区和它的副本构成一个独立的Paxos组，其中一个副本为主（Leader），其它副本为备（Follower）。当OBServer节点出现故障时，Follower分区不受影响，Leader分区的写服务短时间内会受到影响，直到通过Paxos协议将该分区的某个Follower选为新的Leader为止，整个过程不超过30秒。

2. 自动切换Leader的过程

在OceanBase中，当检测到Leader节点故障时，系统会自动触发选举流程。这个过程包括：

• 故障检测 ：通过心跳机制检测到Leader节点故障。
• 选举新Leader ：Paxos协议确保在多数派副本中选举出一个新的Leader。
• 服务接管 ：新选举出的Leader接管原Leader的服务，保证业务连续性。

OceanBase 故障场景下自动补副本

OceanBase数据库系统在设计之初就将高可用性（High Availability, HA）作为核心特性之一。在分布式数据库系统中，数据副本的自动补充是保障数据高可用和容灾能力的关键机制。当系统检测到某个节点发生故障时，OceanBase能够自动进行副本补充，以维持数据的冗余度和系统的稳定性。

自动补副本机制

OceanBase的自动补副本机制主要依赖于其内部的RootService组件。RootService负责管理集群中的服务器节点、租户和资源分配。当集群中的某个节点发生故障，RootService会检测到这一变化，并触发副本补充流程。这个过程包括以下几个关键步骤：

1. 故障检测 ：通过心跳机制，RootService能够实时监控集群中各个节点的状态。一旦检测到节点故障，系统会立即启动故障恢复流程。
2. 副本补充 ：在故障节点被确认为永久下线后，RootService会选择合适的节点来补充新的副本。这个过程会考虑到集群的整体负载、节点的地理位置以及网络拓扑等因素，以确保新副本的补充不会对现有系统造成过大压力。
3. 数据同步 ：新补充的副本会从现有的健康副本中同步数据。OceanBase采用了高效的数据同步算法，确保数据在副本间快速且准确地复制。
4. 负载均衡 ：在副本补充完成后，RootService还会进行负载均衡调整，确保集群中的数据分布均匀，避免某些节点过载。

自动补副本的策略

OceanBase提供了灵活的副本补充策略，以适应不同的业务需求和容灾要求。管理员可以根据业务特点和资源状况，调整副本补充的参数，如副本数量、副本分布策略等。