[MVS]OceanBase日志流介绍

OceanBase日志流介绍

日志流概念

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

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

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

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

广播日志流

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

一般来说，参与一致性协议投票的副本过多，就会导致达成多数派需要的时间越长。在一个租户内的 OBServer 节点较多时，自然不可能让所有的 OBServer 上的副本都参与投票。因此，广播日志流就会在不需要参与投票的 OBServer 上会部署 R 副本（READONLY 副本，只读型副本），在需要参与投票的 OBServer 节点上部署常规的 F 副本（FULL 副本，即全功能型副本）。

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

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

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