OceanBase 学习（二）

1.统一安装包

OceanBase 数据库自 V4.0.0 开始提供统一的安装包 all-in-one package。可以根据实际需求选择部分或全部组件安装。

2.副本与数据分区

副本是 OceanBase 数据库存储引擎中的概念，同一份数据在不同节点的拷贝称为副本，这里的数据是一个用户层面的概念。副本提高了 OceanBase 数据库的可用性和容错性。

数据分区是指根据一定的建表规则，把一个表或者索引分解成多个更小的、更容易管理的部分。每个数据分区都是一个独立的对象，具有自己的名称和可选的存储特性。

在 OceanBase 数据库层面，每个数据分区根据租户的 Locality 属性冗余有多份，从而提供良好的水平扩展性和更高级别的容灾能力。

3.日志流概念

日志流是由 OceanBase 数据库自动创建和管理的实体，它代表了一批数据的集合，包括若干数据分区，及对其进行事务操作的日志和事务管理结构。RedoLog 是基于 Paxos 协议实现的日志模块，实现了多副本间日志同步，保证副本间数据的一致性，实现了数据的高可用。TxCtxMgr 是事务管理结构，日志流内所有数据分区的修改可以在日志流内部完成原子提交，事务跨多个日志流时使用 OceanBase 优化的两阶段提交协议完成事务的原子提交，日志流是分布式事务的参与者。

日志流是 OceanBase 数据库 V4.0 新引入的概念，OceanBase 数据库 V4.0 相比于 OceanBase 数据库 V3.x 最大的改变就是改变了事务提交的基本单位，从而在资源、性能、功能三个方面带来了很大价值。

• 在 OceanBase 数据库 V3.x 中，OceanBase 数据库以分区为单位进行事务提交，分区内的修改由分区内 WAL 保证修改的原子性，每个分区作为两阶段提交的参与者，事务提交的基本单位是分区。

• 在 OceanBase 数据库 V4.x 中，OceanBase 数据库以日志流为单位进行事务提交，日志流内的修改由日志流内 WAL 保证修改的原子性，每个日志流作为两阶段提交的参与者，事务提交的基本单位是日志流。

 4.广播日志流

当某个租户的第一个复制表被创建时，同时系统会创建一个特殊的日志流，称为广播日志流。之后新建的复制表都会创建到这个广播日志流上。广播日志流与普通日志流的不同之处在于，广播日志流会自动地在租户内的每个 OBServer 节点上均部署一个副本，保证在理想情况下复制表可以在任意一个 OBServer 节点上提供强一致性读。

广播日志流会在不需要参与投票的 OBServer 上会部署 R 副本（READONLY 副本，只读型副本），在需要参与投票的 OBServer 节点上部署常规的 F 副本（FULL 副本，即全功能型副本）。

广播日志流与普通日志流对副本的差异如下：

• 对于普通日志流来说，每个 Zone 仅能有一个副本，且该副本类型需要与 Locality 中指定的副本类型匹配。

• 对于广播日志流来说，每个 Zone 内，除了 Locality 中描述的该 zone 的副本类型外，在该 Zone 内其余有该租户 Unit 资源的机器上还会各放置一个只读型副本。对 Locality 中没有指定副本类型的 Zone 不放置任何副本。

广播日志流的使用限制如下：

• sys 租户、所有 Meta 租户均没有广播日志流，不支持复制表创建。

• 每个用户租户最多只能有一个广播日志流。

• 不支持广播日志流和普通日志流之间的属性转换。

• 不支持手动删除广播日志流，当前仅支持广播日志流随着租户的删除而删除。

5.DB流量与ODP 

数据库系统在应用架构中承担了数据存储和查询的功能，应用的读写请求称为数据库流量。数据库流量分为写流量、强一致读流量和弱一致读流量，写流量和强一致读流量由 OceanBase 数据库的 Leader 副本提供服务，弱一致读流量由 Leader 副本和 Follower 副本提供服务。ODP 提供了数据库流量的路由选择能力，ODP 实现了一个简单的 SQL Parser 模块，解析出 SQL 中的库名、表名及 hint ，从而根据业务 SQL、路由规则、及 OBServer 节点的状态，选择最合适的一个 OBServer 节点转发请求。

6.分区表

OceanBase 数据库支持普通表和分区表。分区表又分为一级分区表和二级分区表，分区表由一个或多个分区组成。普通表由一个分区组成，可以看做分区表的特例。OceanBase 数据库的基本分区策略包括范围（Range）分区、列表（List）分区、哈希（Hash）分区、Key 分区等。

 7.ODP

OceanBase 数据库作为一款分布式数据库，数据天然分布于多个节点上。为了屏蔽分布式数据库给应用程序带来的复杂性，使得应用程序访问 OceanBase 数据库像访问单机数据库一样简单，从架构上引入了 ODP，全称是 OceanBase 数据库代理（OceanBase Database Proxy，又称为 OBProxy），ODP 是 OceanBase 专用的反向服务代理，以解决 OceanBase 数据库的 SQL 路由和 容灾问题。

 APPServer 访问 ODP 需要经过一层负载均衡组件，负载均衡组件负责 ODP 的高可用和负载均衡。例如 F5 将请求分散到多台 ODP 上。

引入 ODP 后，OceanBase 的数据链路为 APPServer <-> OBProxy <-> OBServer。APPServer 通过数据库驱动连接 ODP 发送请求，由于 OceanBase 数据库的分布式架构，用户数据以多日志流多副本的方式分布于多个 OBServer 上，ODP 将用户请求转发到最合适的 OBServer 上执行，并将执行结果返回用户。每个 OBServer 也有路由转发的功能，如果发现请求不能在当前节点执行，则会转发请求到正确的 OBServer，该场景需要进行一次远程执行，对请求的 RT（Response Time） 会有一定影响。

8.心跳监测OBServer

在 OceanBase 数据库中，Root Service 负责集群的节点管理，各 OBServer 通过心跳数据包（heartbeat）的方式，定期（每 2s）向 Root Service 汇报自己的进程状态，Root Service 通过监测 OBServer 的心跳数据包，来获取当前 OBServer 进程的工作状态。

Root Service 根据心跳数据包可以获得 OBServer 如下的工作状态：

• OBServer 心跳数据包存在，心跳数据包中的 OBServer 磁盘状态正常。此种状态下，Root Service 认为 OBServer 处于正常工作状态。

• OBServer 心跳数据包存在，心跳数据包中的 OBServer 磁盘状态异常。此种状态下，Root Service 认为 observer 进程还在，但 OBServer 磁盘故障。此种状态下，Root Service 会尝试将该 OBServer 上的全部 leader 副本切走。

• OBServer 心跳数据包不存在，OBServer 心跳数据包的丢失时间还比较短，OBServer 心跳状态为 lease_time，此种状态下，Root Service 仅将 OBServer 的工作状态设置为 inactive，不做其他处理。

• OBServer 心跳数据包不存在，OBServer 心跳数据包丢失时间超过 server_permanent_offline_time，OBServer 的心跳状态为 permanent_offline，此种情况下，Root Service 会对该 OBServer 上的数据副本进行处理，将该 OBServer 上包含的数据副本从 Paxos 成员组中删除，并在其他可用 OBServer 上补充数据，以保证数据副本 Paxos 成员组完整。

9.物理备库

物理备库作为 OceanBase 生产数据库的准实时热备份，当主库出现计划内或计划外（多数派副本故障）的不可用情况时，备库可以接管服务，并且提供无损切换（RPO = 0）和有损切换（RPO > 0）两种容灾能力，最大限度降低服务停机时间，减少可能带来的数据损失。

物理备库主要通过日志传输服务和日志存储服务来完成日志的传输及存储，并通过日志回放服务来保证主备租户数据的一致，其中：

• 日志传输服务在主租户和备租户之间实时同步 Redo 日志。

  当前，OceanBase 数据库物理备库仅提供异步同步模式。

• 日志存储服务为物理备库提供高可用、高可靠的日志存储和读写能力。

• 备租户写入日志存储服务的日志会通过日志回放服务实时或延后地应用到内存的 MemStore 之中，以保证主租户和备租户的数据完全一致。

10. 日志传输服务

物理备库通过日志传输服务在主租户和备租户之间实时同步 Redo 日志。特别的，主租户不会主动给备租户推送日志，仅依赖备租户从主租户拉取日志。

日志传输服务会自动寻址日志位置信息，并处理日志落后及主租户所在集群节点故障等高可用问题。备租户既可以通过主租户的日志归档来获取日志，也可以通过网络直连主租户所在的集群来获取日志。

 基于日志归档的模式

基于网络的模式 

基于网络的物理备库中，备租户直接通过网络连接主租户或其他备租户读取日志，类似于 MySQL 数据库的 Replication。

在该部署模式下，备租户从主租户读取的日志，既可以是主租户的在线日志，也可以是主租户的归档日志（主租户开启了日志归档模式的前提下），两种日志来源支持自动切换，对备租户以及业务的使用者透明

11.日志存储服务

日志存储服务为物理备库提供高可用、高可靠的日志存储和读写能力。日志存储服务既支持单副本，也支持多副本，并通过使用 Paxos 协议来实现高可用

主租户和备租户中的日志存储服务使用了两种不同的工作模式：

• APPEND 模式

  主租户上使用 APPEND 模式。在该模式下，主租户日志流的 Leader 会接收事务、DDL 等上层模块写入的数据，并将这些数据在主租户的多个副本之间使用 Paxos 协议进行同步并持久化。在数据同步过程中，如果发生故障，则写入的数据就可能会持久化失败，而日志存储服务可以自动处理各类失败场景，提供高可用能力。

  在数据同步过程中，每一条日志都会在主租户上生成一组唯一的 LSN 和 SCN 值。其中，LSN 用于定位这条日志在存储服务中的物理位置信息；SCN 用于代表这条日志在存储服务中的时序关系，上层服务可以使用 SCN 值对多个日志流之间的日志进行定序。

• RAW_WRITE 模式

  备租户上使用 RAW_WRITE 模式。在该模式下，备租户日志流的 Leader 拒绝任何上层模块直接写入的数据，仅允许通过日志传输服务从主租户同步物理日志，且这些物理日志的内容、LSN、SCN 等信息均由主租户生成。

  从主租户同步过来的物理日志会在备租户的日志存储服务的多个副本之间使用 Paxos 协议进行同步并持久化。

在创建主租户或备租户的 Unit 规格时，可以通过 CREATE RESOURCE UNIT 命令中的 LOG_DISK_SIZE 参数指定日志盘的存储空间，如果创建时未指定 LOG_DISK_SIZE，则其默认值为内存规格的 3 倍大小，且日志盘的最小值为 2G。

12.闪回查询

OceanBase 数据库提供了记录级别的闪回查询（Flashback Query）功能，该功能允许用户获取某个历史版本的数据。其中，Oracle 模式支持 AS OF SCN和 AS OF TIMESTAMP 两种语法来查询；MySQL 模式支持通过 AS OF SNAPSHOT 语法来查询。

OceanBase 数据库当前支持用户通过设置租户级配置项 undo_retention 的方式来进行闪回查询。当用户设置 undo_retention 后，即可使用闪回查询功能查询当前时间 T 到 T - undo_retention 时间范围内的任意多版本数据。租户级配置项 undo_retention 的默认值为 1800，单位为秒。

13.OceanBase 数据库的安全体系

 14.OceanBase视图示意图

OceanBase 数据库的物理架构和逻辑架构，其相应的数据字典视图以如下示意图表示。

15. OceanBase Online DDL 设计

具体内容请参阅《OceanBase 4.0解读：兼顾高效与透明，我们对DDL的设计与思考》-- https://zhuanlan.zhihu.com/p/606907652?utm_id=0

学习转载

官网

https://www.oceanbase.com/docs/oceanbase-database-cn

热门相关：现代隐士高手   一等狂后：绝色驭兽师   我的黑月光女友   都市最强小村医   惊世第一妃：魔帝，宠上身！