暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

OceanBase数据库副本介绍

Tonyhacks 2023-12-08
625

副本介绍

副本概念

副本是 OceanBase 数据库存储引擎中的概念,同一份数据在不同节点的拷贝称为副本,这里的数据是一个用户层面的概念。
在 OceanBase 数据库层面,我们指数据分区,每个数据分区根据租户的 Locality 属性冗余有多份,从而提供良好的水平扩展性和更高级别的容灾能力。
数据分区是指根据一定的建表规则,把一个表或者索引分解成多个更小的、更容易管理的部分。每个数据分区都是一个独立的对象,具有自己的名称和可选的存储特性。

说明

OceanBase 数据库以多副本架构著称,基于 Paxos 协议的多副本架构是高可用能力的基础。多副本中的“副本”本质是同一份数据在不同节点的拷贝,而数据在 OceanBase 数据库中有多种层面的承载容器,例如数据分区、日志流、Unit、租户等。一般情况下我们提及的“副本”往往是指“数据分区副本”。但需要注意的是,不同语境下的“副本”可能对应着不同的数据库实体。

副本的作用

副本提高了 OceanBase 数据库的可用性和容错性,副本可以被分配在不同的地理位置,以应对网络故障或数据中心故障。
OceanBase 数据库通过分区复制、日志同步等方式将数据复制到多个副本以防止数据丢失,确保 OceanBase 数据库在少数派副本故障的情况下依然能够提供无损的数据库服务。

副本的类型

OceanBase 数据库的存储引擎采用分层 LSM-Tree 结构,数据分为两部分:基线数据和增量数据。
基线数据是持久到磁盘上的数据,一旦生成就不会再修改,称之为 SSTable。
增量数据存在于内存,用户写入都是先写到增量数据,称之为 MemTable,通过 RedoLog 来保证事务性(也称为 CommitLog,简称 CLog)。
这些数据冗余有多份(例如,同城三中心部署架构为 3 个,三地五中心部署架构为 5 个),分布于多个节点上。事务提交时利用 Paxos 协议在多个节点间同步 RedoLog 达成多数派提交,从而维护副本间数据的一致性。
OceanBase 数据库当前版本支持的副本类型为全功能型副本和只读型副本,全功能型副本也称为普通副本,其名称为 FULL,简称 F,拥有 RedoLog、MemTable 和 SSTable 等全部完整的数据和功能。只读型副本的名称为 READONLY,简称 R,区别于全功能副本,只读副本提供读的能力,不提供写的能力,只能作为日志流的 Follower 副本,不参与选举及日志的投票,不能当选为日志流的 Leader 副本。
全功能副本有角色的概念,即数据分区有角色的概念,分别是 Leader 和 Follower。Leader 主要对外提供写服务和强一致读服务,也可以提供弱一致读服务。Follower 对外提供弱一致读服务,在 Leader 故障的情况下还可以快速切换为 Leader 对外提供服务。

日志流介绍

日志流概念

日志流是由 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 不放置任何副本。

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

  • sys 租户、所有 Meta 租户均没有广播日志流,不支持复制表创建。
  • 每个用户租户最多只能有一个广播日志流。
  • 不支持广播日志流和普通日志流之间的属性转换。
  • 不支持手动删除广播日志流,当前仅支持广播日志流随着租户的删除而删除。

查看日志流的基本信息

通过 DBA_OB_LS 视图可以查看本租户所有日志流的基本信息,包括状态、日志进度等。例如:

  • 查看普通日志流信息系统租户和用户租户均可以查看本租户对应的日志流的基本信息。例如以下示例在系统租户中执行,所示为系统租户仅有的一个 1 号日志流。
  • 查看广播日志流信息仅用户租户可以查看广播日志流信息,系统租户没有广播日志流。以下示例为在用户租户上执行,所示为用户租户的广播日志流信息,复制表就创建在该日志流上。

查看日志流的位置信息和角色信息

日志流具有位置信息,记录了其分布于哪些节点,可以通过 oceanbase.DBA_OB_LS_LOCATIONS 视图的 MEMBER_LIST 字段和 LEARNER_LIST 字段分别查看全功能型副本和只读型副本的分布情况。数据分区不再独立拥有位置信息,而是由其归属于的日志流位置决定。日志流支持在不同节点之间迁移和复制,以达到性能均衡和容灾的目的。
日志流具有角色信息,记录其是 LEADER 还是 FOLLOWER,可以通过 oceanbase.DBA_OB_LS_LOCATIONS 视图的 ROLE 字段查看。数据分区不再独立拥有角色信息,而是由其归属于的日志流角色决定。日志流角色通过选举协议产生。
关于视图 oceanbase.DBA_OB_LS_LOCATIONS的详细介绍,参见 DBA_OB_LS_LOCATIONS

查看数据分区到日志流的映射

通过 DBA_OB_TABLE_LOCATIONS 视图可以查看本租户数据分区到日志流的映射,其中每个数据分区的每个副本都是一条记录,记录了该数据分区的基本信息,及其所归属的日志流信息。
关于视图 oceanbase.DBA_OB_TABLE_LOCATIONS的详细介绍,参见 DBA_OB_TABLE_LOCATIONS

SELECT * FROM oceanbase.DBA_OB_LS limit 10;

结果如下。

+-------+--------+----------------------------------------+---------------+-------------+------------+----------+----------+--------------+ | LS_ID | STATUS | PRIMARY_ZONE | UNIT_GROUP_ID | LS_GROUP_ID | CREATE_SCN | DROP_SCN | SYNC_SCN | READABLE_SCN | +-------+--------+----------------------------------------+---------------+-------------+------------+----------+----------+--------------+ | 1 | NORMAL | sa128_obv4_2;sa128_obv4_1,sa128_obv4_3 | 0 | 0 | NULL | NULL | NULL | NULL | +-------+--------+----------------------------------------+---------------+-------------+------------+----------+----------+--------------+ 1 row in set
SELECT * FROM oceanbase.DBA_OB_LS WHERE flag LIKE "%DUPLICATE%";

结果如下。

+-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+ | LS_ID | STATUS | PRIMARY_ZONE | UNIT_GROUP_ID | LS_GROUP_ID | CREATE_SCN | DROP_SCN | SYNC_SCN | READABLE_SCN | FLAG | +-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+ | 1003 | NORMAL | z1;z2 | 0 | 0 | 1683267390195713284 | NULL | 1683337744205408139 | 1683337744205408139 | DUPLICATE | +-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论